From daemon@optimus.ietf.org Fri Feb 1 12:12:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04320 for ; Fri, 1 Feb 2002 12:12:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28012 for enum-archive@odin.ietf.org; Fri, 1 Feb 2002 12:12:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27135; Fri, 1 Feb 2002 12:02:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27105 for ; Fri, 1 Feb 2002 12:02:20 -0500 (EST) Received: from redstorm.unimessage.net (redstorm.unimessage.net [212.6.90.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03649 for ; Fri, 1 Feb 2002 12:02:16 -0500 (EST) From: steinle@smartvia.de Received: from mouse.unimessage.net (root@mouse.unimessage.net [212.6.90.252]) by redstorm.unimessage.net (8.10.2/8.10.2) with ESMTP id g11H0QN14125 for ; Fri, 1 Feb 2002 18:00:26 +0100 (MET) Date: Fri, 1 Feb 2002 18:00:26 +0100 (MET) Message-ID: <567725408.1012582922936.JavaMail.root@mouse.unimessage.net> To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Canbox-Sender: steinle@smartvia.de X-Canbox-MsgType: email X-Canbox-SendDate: 1012582855773 X-Canbox-UserName: steinle X-Canbox-ServiceGroup: smartvia Content-Transfer-Encoding: 7bit Subject: [Enum] E.164 number blocking Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Nowadays Telcos are able to block some phone numbers. E.g. some mobile telecommunication operators don't provide access to freephone services. The mobile operators may be afraid that it will be used as means of Indirect Access by other carriers. In future could a Telco still block a phone number that has ENUM enabled? Or will this not be possible by architecture of ENUM? With my uneducated technical intellect I would say blocking will still be possible if a standard telephone is used but won't if a Internet-enabled telephone is used. I'm not an engineer, so could someone please enlighten me? Thanks in advance, Simon p.s. are there any other ENUM lists which are worth to subscribe? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 1 12:39:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05330 for ; Fri, 1 Feb 2002 12:39:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29979 for enum-archive@odin.ietf.org; Fri, 1 Feb 2002 12:39:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29126; Fri, 1 Feb 2002 12:30:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29098 for ; Fri, 1 Feb 2002 12:30:23 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05042 for ; Fri, 1 Feb 2002 12:30:06 -0500 (EST) Received: from [10.1.1.90] (confmad-isdn.cisco.com [10.49.42.193]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA29963; Fri, 1 Feb 2002 18:29:31 +0100 (MET) Date: Fri, 01 Feb 2002 18:27:22 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: steinle@smartvia.de, enum@ietf.org Subject: Re: [Enum] E.164 number blocking Message-ID: <3649806.1012588042@localhost> In-Reply-To: <567725408.1012582922936.JavaMail.root@mouse.unimessage.net> References: <567725408.1012582922936.JavaMail.root@mouse.unimessage.net> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-01 18.00 +0100 steinle@smartvia.de wrote: > In future could a Telco still block a phone number that has ENUM enabled? > Or will this not be possible by architecture of ENUM? ENUM has nothing to do with the actual setup of the call itself. It is only a service which gives it possible for the caller to know where the callee want the service routed. What you talk about is a policy which a telco close to the calling part is applying to certain destination numbers. ENUM is about ability for the called party to express a policy for where he want to be contacted. Regards, paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 1 21:14:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16336 for ; Fri, 1 Feb 2002 21:14:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA23795 for enum-archive@odin.ietf.org; Fri, 1 Feb 2002 21:14:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23425; Fri, 1 Feb 2002 21:05:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23398 for ; Fri, 1 Feb 2002 21:05:21 -0500 (EST) Received: from user (p121.as2.virginia1.eircom.net [159.134.184.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16182 for ; Fri, 1 Feb 2002 21:05:06 -0500 (EST) Message-Id: <200202020205.VAA16182@ietf.org> From: "info" To: "enum" Date: Sat, 02 Feb 02 01:01:05 GMT Standard Time MIME-Version: 1.0 Content-Type: multipart/mixed;boundary= "----=_NextPart_000_0016_BBF3D8C9.F42FD31F" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Subject: [Enum] Special Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org ------=_NextPart_000_0016_BBF3D8C9.F42FD31F Content-Type: text/html; charset= "US-ASCII" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5QdXQgdGhlIEludGVybmV0IHRvIFdvcmsg Zm9yIFlvdSE8L1RJVExFPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNI VE1MIDUuMDAuMjkxOS42MzA3IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0K PC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZjk5Pg0KPEJMT0NLUVVPVEUgPERJVj4NCiAg PERJViBhbGlnbj1jZW50ZXI+PFNUUk9ORz48Rk9OVCBmYWNlPSJBcmlhbCBCbGFjayIgc2l6 ZT01PjxBIA0KICBocmVmPSJodHRwOi8vd3d3LkJ1c2luZXNzbWFpbGxpc3QuY29tIj53d3cu QnVzaW5lc3NtYWlsbGlzdC5jb208L0E+Jm5ic3A7PC9GT05UPjwvU1RST05HPjwvRElWPg0K ICA8RElWIGFsaWduPWNlbnRlcj4mbmJzcDs8U1RST05HPjxGT05UIGZhY2U9IkFyaWFsIEJs YWNrIiANCiAgc2l6ZT01PjwvRk9OVD48L1NUUk9ORz48L0RJVj4NCiAgPERJViBhbGlnbj1j ZW50ZXI+PFNUUk9ORz48Rk9OVCBmYWNlPSJBcmlhbCBCbGFjayIgc2l6ZT01PiZuYnNwOyAN CiAgPC9GT05UPjwvU1RST05HPjxTVFJPTkc+PEZPTlQgZmFjZT0iQXJpYWwgQmxhY2siIHNp emU9NT5UaGUgTm8uMSBQcm9mZmVzaW9uYWwgDQogIE1haWxpbmcgbGlzdDwvRk9OVD48L1NU Uk9ORz48L0RJVj48QlI+DQogIDxESVY+PC9ESVY+DQogIDxUQUJMRSBhbGlnbj1jZW50ZXIg Ym9yZGVyPTAgY2VsbFBhZGRpbmc9MCBjZWxsU3BhY2luZz0wIHdpZHRoPTY0MD4NCiAgICA8 VEJPRFk+DQogICAgPFRSPg0KICAgICAgPFREPjxJTUcgYWx0PSIiIGJvcmRlcj0wIGhlaWdo dD00NSANCiAgICAgICAgc3JjPSJodHRwOi8vd2ViMS5jdXN0b21vZmZlcnMuY29tL2NyZWF0 aXZlL2ZyZWVtb25leS9UaGVJbnRlcm5ldF8wMS5naWYiIA0KICAgICAgICB3aWR0aD01NjU+ PEJSPjxJTUcgYWx0PSIiIGJvcmRlcj0wIGhlaWdodD01OCANCiAgICAgICAgc3JjPSJodHRw Oi8vd2ViMS5jdXN0b21vZmZlcnMuY29tL2NyZWF0aXZlL2ZyZWVtb25leS9UaGVJbnRlcm5l dF8wMy5naWYiIA0KICAgICAgICB3aWR0aD01NjU+PEJSPjxJTUcgYWx0PSIiIGJvcmRlcj0w IGhlaWdodD01NyANCiAgICAgICAgc3JjPSJodHRwOi8vd2ViMS5jdXN0b21vZmZlcnMuY29t L2NyZWF0aXZlL2ZyZWVtb25leS9UaGVJbnRlcm5ldF8wNC5naWYiIA0KICAgICAgICB3aWR0 aD01NjU+PC9URD4NCiAgICAgIDxURD48SU1HIGFsdD0iIiBib3JkZXI9MCBoZWlnaHQ9MTYw IA0KICAgICAgICBzcmM9Imh0dHA6Ly93ZWIxLmN1c3RvbW9mZmVycy5jb20vY3JlYXRpdmUv ZnJlZW1vbmV5L1RoZUludGVybmV0XzAyLmpwZyIgDQogICAgICAgIHdpZHRoPTc1PjwvVEQ+ PC9UUj4NCiAgICA8VFI+DQogICAgICA8VEQ+DQogICAgICAgIDxUQUJMRSBhbGlnbj1jZW50 ZXIgYm9yZGVyPTAgY2VsbFBhZGRpbmc9MyBjZWxsU3BhY2luZz0wIHdpZHRoPTUxNT4NCiAg ICAgICAgICA8VEJPRFk+DQogICAgICAgICAgPFRSPg0KICAgICAgICAgICAgPFREIGFsaWdu PW1pZGRsZT4NCiAgICAgICAgICAgICAgPERJVj48Rk9OVCBjb2xvcj0jMDA2NjAwIA0KICAg ICAgICAgICAgICBmYWNlPVZlcmRhbmEsQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY+PEZP TlQgY29sb3I9I2ZmNjYwMCANCiAgICAgICAgICAgICAgc2l6ZT0rMT5XZSBoYXZlIDEwMDAn cyBvZiBtZW1iZXJzIG9uIG91ciANCiAgICAgICAgICAgICAgc2VydmljZTwvRk9OVD48L0ZP TlQ+PC9ESVY+DQogICAgICAgICAgICAgIDxESVY+PEZPTlQgY29sb3I9IzAwNjYwMCANCiAg ICAgICAgICAgICAgZmFjZT1WZXJkYW5hLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmPjxG T05UIGNvbG9yPSNmZjY2MDAgDQogICAgICAgICAgICAgIHNpemU9KzE+VGhleSBhcmUgd2Fp dGluZyB0byByZWNlaXZlIHlvdXIgDQogICAgICAgICAgICAgIGFkdmVydCE8L0ZPTlQ+PC9G T05UPjwvRElWPg0KICAgICAgICAgICAgICA8RElWPjxGT05UIGNvbG9yPSMwMDY2MDAgDQog ICAgICAgICAgICAgIGZhY2U9VmVyZGFuYSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgICAgICAgICAgIDxESVY+PEZPTlQgZmFjZT1WZXJk YW5hLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmPjxGT05UIA0KICAgICAgICAgICAgICBj b2xvcj0jZmY2NjAwIHNpemU9ND5XZSB3aWxsIGJsYXN0IG91dCB5b3VyIGFkdmVydCB3aXRo IG91ciBvcHQtaW4gDQogICAgICAgICAgICAgIGJsYXN0ZXJzPEJSPjwvRk9OVD48L0RJVj48 L0ZPTlQ+DQogICAgICAgICAgICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPSJB cmlhbCBCbGFjayIgDQogICAgICAgICAgICAgIHNpemU9NT48U1RST05HPjxVPlNwZWNpYWwg b2ZmZXIgcHJpY2Ugb2YgDQogICAgICAgICAgICAgICQxOS45NTwvVT48L1NUUk9ORz48L0ZP TlQ+PC9ESVY+DQogICAgICAgICAgICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNl PSJBcmlhbCBCbGFjayI+PFNUUk9ORz5UaGlzIG9mZmVyIA0KICAgICAgICAgICAgICBlbmRz IGF0IHRoZSBlbmQgb2YgRmViPC9TVFJPTkc+PC9GT05UPjwvRElWPg0KICAgICAgICAgICAg ICA8RElWPjxGT05UIGNvbG9yPSMwMDY2MDAgDQogICAgICAgICAgICAgIGZhY2U9VmVyZGFu YSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZj48QlI+V2UnbGwgaGVscCB5b3UgZG8gDQog ICAgICAgICAgICAgIGl0ITxCUj48QlI+SXQncyBlYXN5IHRvIHR1cm4gdGhlIGludGVybmV0 IGludG8geW91ciBvd24gMjQvNyANCiAgICAgICAgICAgICAgYnVzaW5lc3MgYW5kIGVhcm4g YW4gZXhlY3V0aXZlJ3Mgc2FsYXJ5ITxCUj48QlI+PEI+RmluYW5jaWFsIA0KICAgICAgICAg ICAgICBmcmVlZG9tIGlzIG9ubHkgYSBjbGljayBhd2F5ITwvQj48L0ZPTlQ+PEJSPjxBIA0K ICAgICAgICAgICAgICBocmVmPSJodHRwOi8vd3d3LmJ1c2luZXNzbWFpbGxpc3QuY29tIj48 SU1HIGFsdD0iIiBib3JkZXI9MCANCiAgICAgICAgICAgICAgaGVpZ2h0PTQwIGhzcGFjZT0w IA0KICAgICAgICAgICAgICBzcmM9Imh0dHA6Ly93ZWIxLmN1c3RvbW9mZmVycy5jb20vY3Jl YXRpdmUvZnJlZW1vbmV5L1RoZUludGVybmV0Q2xpY2suZ2lmIiANCiAgICAgICAgICAgICAg c3R5bGU9IkhFSUdIVDogNDBweDsgV0lEVEg6IDEzMHB4IiB2c3BhY2U9MyB3aWR0aD0xMzA+ PC9BPiANCiAgICAgICAgICAgIDwvRElWPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PC9U RD4NCiAgICAgIDxURCB2QWxpZ249dG9wPjxJTUcgYWx0PSIiIGJvcmRlcj0wIGhlaWdodD0z NiANCiAgICAgICAgc3JjPSJodHRwOi8vd2ViMS5jdXN0b21vZmZlcnMuY29tL2NyZWF0aXZl L2ZyZWVtb25leS9UaGVJbnRlcm5ldF8wNi5qcGciIA0KICAgICAgICB3aWR0aD03NT4gDQog ICAgICAgIDxQPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxBIA0KICAgICAgICBocmVmPSJo dHRwOi8vd3d3LmR5bmFtaWNzbXMuY29tLmF1L2ludHJvLmFzcD9yZWY9MDg2ODY2NDEzMyZh bXA7cmVmYz0zMjEiPjwvQT48L0ZPTlQ+PC9QPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+ DQogIDxESVYgYWxpZ249Y2VudGVyPjxJTUcgYm9yZGVyPTAgaGVpZ2h0PTIwIA0KICBzcmM9 Imh0dHA6Ly93ZWIxLmN1c3RvbW9mZmVycy5jb20vY3JlYXRpdmUvZnJlZW1vbmV5L1RoZUlu dGVybmV0XzA4LmpwZyIgDQogIHdpZHRoPTY0MD48L0RJVj4NCiAgPFA+Jm5ic3A7PC9QPjwh LS0zNzAwMDUwMS0tPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0KICAgIA== ------=_NextPart_000_0016_BBF3D8C9.F42FD31F-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 2 19:25:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09197 for ; Sat, 2 Feb 2002 19:25:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA19455 for enum-archive@odin.ietf.org; Sat, 2 Feb 2002 19:25:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19209; Sat, 2 Feb 2002 19:16:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19169 for ; Sat, 2 Feb 2002 19:16:09 -0500 (EST) Received: from localhost ([211.183.238.87]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09075 for ; Sat, 2 Feb 2002 19:16:06 -0500 (EST) Message-Id: <200202030016.TAA09075@ietf.org> Reply-To: office700@yahoo.co.kr From: 성인정보 To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 3 Feb 2002 09:13:45 +0900 Subject: [Enum] [광고[ 어른들의 놀이동산 [미성년자제한구역] Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org 다음 사항을 선택하시면 귀하의 의사를 존중하겠습니다.

 

귀하의 메일주소는 웹서핑중, http://www.xxxxxxxx.com/
에서 알게 된것이며, E-Mail 주소 외에, 다른 정보는 갖고 있지 않습니다.
정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다.수신거부를 눌러주세요

 

_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 2 20:21:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09600 for ; Sat, 2 Feb 2002 20:21:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA21351 for enum-archive@odin.ietf.org; Sat, 2 Feb 2002 20:21:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21108; Sat, 2 Feb 2002 20:12:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21077 for ; Sat, 2 Feb 2002 20:12:45 -0500 (EST) Received: from whale.cnnic.net.cn ([159.226.6.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09508 for ; Sat, 2 Feb 2002 20:12:42 -0500 (EST) Received: from cnnicenum1 ([159.226.7.98]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GQXNF200.FFA; Sun, 3 Feb 2002 09:13:50 +0800 Message-ID: <001c01c1ac4f$cb9f8eb0$6207e29f@cnnicenum1> From: "bill" To: Cc: References: <567725408.1012582922936.JavaMail.root@mouse.unimessage.net> Subject: Re: [Enum] E.164 number blocking Date: Sun, 3 Feb 2002 09:12:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id UAA21078 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit ----- Original Message ----- From: To: Sent: Saturday, February 02, 2002 1:00 AM Subject: [Enum] E.164 number blocking > Nowadays Telcos are able to block some phone numbers. E.g. some mobile telecommunication operators don't provide access to freephone services. The mobile operators may be afraid that it will be used as means of Indirect Access by other carriers. > > In future could a Telco still block a phone number that has ENUM enabled? > Or will this not be possible by architecture of ENUM? I think the telcos still can do what they have done now after the global or national launch of ENUM system. There's a great deal of policy problems needed to be solved. It is the responsibility of authority of national government who decides what ENUM can do and can not. > With my uneducated technical intellect I would say blocking will still be possible if a standard telephone is used but won't if a Internet-enabled telephone is used. Technically, no matter what telephone is used, blocking is possible. It's an adminstrative problem rather than technical one. > I'm not an engineer, so could someone please enlighten me? > > Thanks in advance, > > Simon > > p.s. are there any other ENUM lists which are worth to subscribe? www.enum-forum.org > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 5 01:44:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15830 for ; Tue, 5 Feb 2002 01:44:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA07280 for enum-archive@odin.ietf.org; Tue, 5 Feb 2002 01:44:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05626; Tue, 5 Feb 2002 01:29:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05602 for ; Tue, 5 Feb 2002 01:29:19 -0500 (EST) Received: from relay5.kornet.net ([211.48.62.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15481 for ; Tue, 5 Feb 2002 01:29:13 -0500 (EST) Received: from localhost (61.72.201.10) by relay5.kornet.net; 5 Feb 2002 15:28:42 +0900 Message-ID: <3c5f7b9c3ca44655@relay5.kornet.net> (added by relay5.kornet.net) Reply-To: test@test.com From: test To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 5 Feb 2002 15:31:17 +0900 Subject: [Enum] (no subject) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org
안녕하십니까?
"우일산업"입니다
먼저 허락없이 이글을 띄워 죄송합니다.
 
다름이 아니라 국내에서 순수하게 개발된 "용접대체신제품'
금속*콘크리트 초강력 보수접착제 및 내구성이강한 특수 방식 방수제등
신기술 9종류를 소개하고자 합니다.
특징은  1.  남녀노소 누구나 손쉽게 사용할 수  있다는것과
              2.  가정은 물론이고 건축설비, 주택보수, 선박등 다양하게 사용되며
              3.  아주 저렴한 가격으로 판매되어  공사및 작업보수비가
                   매우 적은 비용으로 해결됩니다... 
 
군부대로만 납품하던것을  공공기관이나,건축설비,선박,
공공주택하자보수업체등 다용도로 납품이 되고 있으며,
이제는 소비자들 개개인에게까지 보급하고자 글을 올립니다. 
 
그냥 지나쳐 버리지 마시고 잠깐의 시간을 내셔서
저희 홈페이지인  ☞ www.wooil21.com  오시면
더 자세한 설명과 더 좋은 상품을 만나실수 있을 것입니다.

더 궁금한 사항이 있으시면 02) 967-6704로 연락 주세요
감사합니다.
_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 5 10:51:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05204 for ; Tue, 5 Feb 2002 10:51:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08506 for enum-archive@odin.ietf.org; Tue, 5 Feb 2002 10:51:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07603; Tue, 5 Feb 2002 10:39:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07557 for ; Tue, 5 Feb 2002 10:39:50 -0500 (EST) Received: from core.com (d165.as1.lnng.mi.voyager.net [209.153.135.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04404 for ; Tue, 5 Feb 2002 10:39:46 -0500 (EST) Message-Id: <200202051539.KAA04404@ietf.org> From: "Information Management & Marketing, LLC" To: Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Date: Tue, 5 Feb 2002 10:36:12 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Enum] Re:Qualified & Guaranteed Leads Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit
 

QUALIFIED LEADS

$100 Per Appointment!!!

We'll GUARANTEE you in writing that we'll provide you with QUALIFIED COMMERCIAL LEADS!

Don't Pay For No Shows!!!  Don't Pay For Poor Leads!!!  Don't Pay For Unqualified Leads!!!

We've developed the winning techniques...

That's why we are so confident in our ability to provide you with top quality commercial appointments with the decision makers who run their businesses.  That's also why we only charge you for the appointments that stick!!!  If you want to increase your commercial sales we can help you.

Check out our site, give us a call, or e-mail today...

Visit us at www.imm-marketing.com, CONTACT US by e-mail, or give us a call toll free at 1-800-683-0545. We'll share our thoughts and strategies on how we will help you reach your goals and your numbers!

____________________________________________

If you have received this message by error or would like to be removed from our mailing list simply hit reply and type remove.  Be sure to include the e-mail address you would like removed from our list.

 

 

 

_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 5 10:58:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05638 for ; Tue, 5 Feb 2002 10:58:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08921 for enum-archive@odin.ietf.org; Tue, 5 Feb 2002 10:58:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08193; Tue, 5 Feb 2002 10:47:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08155 for ; Tue, 5 Feb 2002 10:47:02 -0500 (EST) Received: from infomail.es (nie2.infomail.es [195.235.39.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04929 for ; Tue, 5 Feb 2002 10:46:58 -0500 (EST) Received: from default ([172.24.120.34]) by infomail.es (Tid InfoMail Exchanger v2.20) with SMTP id #1012923852.091230043; Tue, 5 Feb 2002 16:44:12 +0100 Received: by (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256B57.00562FC9 ; Tue, 5 Feb 2002 16:41:23 +0100 X-Lotus-FromDomain: TDE From: "Information Management & Marketing, LLC" To: enum@ietf.org Message-ID: Date: Tue, 5 Feb 2002 15:36:12 +0000 Subject: [Enum] Re:Qualified & Guaranteed Leads Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=oONluuei1FrCiP8ey410bHifN1i7hu38wRcivMzHVz7t9GLCfgMCrvab" Content-Disposition: attachment X-Infomail-Id: 1012923853.23A32B0A81107C.3853 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --0__=oONluuei1FrCiP8ey410bHifN1i7hu38wRcivMzHVz7t9GLCfgMCrvab Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjcxMi4zMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9IkNlbnR1cnkgU2Nob29s Ym9vayIgY29sb3I9I2ZmMDAwMCBzaXplPTU+Jm5ic3A7PC9GT05UPiANCjxQIGFsaWduPWNlbnRl cj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9Nz5RVUFMSUZJRUQNCkxFQURTPC9GT05UPjwvUD48 Qj48Rk9OVCANCmZhY2U9IkNlbnR1cnkmIzEzOyYjMTA7U2Nob29sYm9vayIgc2l6ZT01Pg0KPFAg YWxpZ249Y2VudGVyPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT02PiQxMDAgUGVyDQpBcHBvaW50 bWVudCEhITwvRk9OVD48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PEZPTlQgY29sb3I9IzAwMDA4MD48 L0ZPTlQ+PC9QPjwvRk9OVD48Rk9OVCANCmZhY2U9IkNlbnR1cnkgU2Nob29sYm9vayIgc2l6ZT01 Pg0KPFAgYWxpZ249Y2VudGVyPjwvRk9OVD48Rk9OVCBmYWNlPSJDZW50dXJ5IFNjaG9vbGJvb2si IHNpemU9NT48Rk9OVCANCmNvbG9yPSMwMDAwODA+V2UnbGwgR1VBUkFOVEVFIHlvdSBpbiB3cml0 aW5nIHRoYXQgd2UnbGwgcHJvdmlkZSB5b3Ugd2l0aCANClFVQUxJRklFRCBDT01NRVJDSUFMIExF QURTITwvRk9OVD48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZP TlQ+PC9QPjwvRk9OVD48Rk9OVCANCmZhY2U9IkNlbnR1cnkgU2Nob29sYm9vayIgY29sb3I9IzAw MDA4MCBzaXplPTQ+DQo8UCBhbGlnbj1jZW50ZXI+PEZPTlQgY29sb3I9IzAwMDBmZj5Eb24ndCBQ YXkgRm9yIE5vIFNob3dzISEhJm5ic3A7IERvbid0DQpQYXkgDQpGb3IgUG9vciBMZWFkcyEhISZu YnNwOyBEb24ndCBQYXkgRm9yIFVucXVhbGlmaWVkIA0KTGVhZHMhISE8L0ZPTlQ+PC9QPjwvQj48 L0ZPTlQ+PEZPTlQgZmFjZT0iQ2VudHVyeSBTY2hvb2xib29rIiBjb2xvcj0jMDAwMGZmPg0KPFA+ PC9GT05UPjxGT05UIGZhY2U9IkNlbnR1cnkgU2Nob29sYm9vayIgY29sb3I9IzAwMDA4MA0Kc2l6 ZT00PjxTVFJPTkc+V2UndmUgDQpkZXZlbG9wZWQgdGhlIHdpbm5pbmcgdGVjaG5pcXVlcy4uLjwv U1RST05HPjwvUD48L0ZPTlQ+PEZPTlQgDQpmYWNlPSJDZW50dXJ5IFNjaG9vbGJvb2siIGNvbG9y PSMwMDAwZmY+DQo8UD5UaGF0J3Mgd2h5IHdlIGFyZSBzbyBjb25maWRlbnQgaW4gb3VyIGFiaWxp dHkgdG8gcHJvdmlkZSB5b3Ugd2l0aCB0b3ANCnF1YWxpdHkgDQpjb21tZXJjaWFsIGFwcG9pbnRt ZW50cyB3aXRoIHRoZSBkZWNpc2lvbiBtYWtlcnMgd2hvIHJ1biB0aGVpcg0KYnVzaW5lc3Nlcy4m bmJzcDsgDQpUaGF0J3MgYWxzbyB3aHkgd2Ugb25seSBjaGFyZ2UgeW91IGZvciB0aGUgYXBwb2lu dG1lbnRzIHRoYXQNCnN0aWNrISEhJm5ic3A7IElmIA0KeW91IHdhbnQgdG8gaW5jcmVhc2UgeW91 ciBjb21tZXJjaWFsIHNhbGVzIHdlIGNhbiBoZWxwIHlvdS48L1A+PC9GT05UPjxGT05UIA0KZmFj ZT0iQ2VudHVyeSBTY2hvb2xib29rIiBjb2xvcj0jMDAwMDgwIHNpemU9ND4NCjxQPjxTVFJPTkc+ Q2hlY2sgb3V0IG91ciBzaXRlLCBnaXZlIHVzIGEgY2FsbCwgb3IgZS1tYWlsIA0KdG9kYXkuLi48 L1NUUk9ORz48L1A+PC9GT05UPjxGT05UIGZhY2U9IkNlbnR1cnkgU2Nob29sYm9vayIgY29sb3I9 IzAwMDBmZj4NCjxQPlZpc2l0IHVzIGF0IDwvRk9OVD48QSBocmVmPSJodHRwOi8vd3d3LmltbS1t YXJrZXRpbmcuY29tIj48Rk9OVCANCmZhY2U9IkFuZGFsZSBNb25vIiBzaXplPTQ+d3d3LmltbS1t YXJrZXRpbmcuY29tPC9GT05UPjwvQT48Rk9OVCANCmZhY2U9IkNlbnR1cnkgU2Nob29sYm9vayIg Y29sb3I9IzAwMDBmZj4sIDxBDQpocmVmPSJtYWlsdG86aW1tQGNvcmUuY29tIj5DT05UQUNUIA0K VVMgPC9BPmJ5IGUtbWFpbCwgb3IgZ2l2ZSB1cyBhIGNhbGwgdG9sbCBmcmVlIGF0IDEtODAwLTY4 My0wNTQ1LiBXZSdsbA0Kc2hhcmUgb3VyIHRob3VnaHRzIA0KYW5kIHN0cmF0ZWdpZXMgb24gaG93 IHdlIHdpbGwgaGVscCB5b3UgPFNUUk9ORz5yZWFjaCB5b3VyIGdvYWxzIGFuZCB5b3VyIA0KbnVt YmVycyE8L1NUUk9ORz48L1A+DQo8UD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvUD4NCjxQPjxGT05UIGNvbG9yPSNmZjAwMDA+SWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBtZXNzYWdlIGJ5IGVycm9yIG9yIHdvdWxkDQpsaWtlIA0KdG8gYmUgcmVtb3ZlZCBm cm9tIG91ciBtYWlsaW5nIGxpc3Qgc2ltcGx5IGhpdCByZXBseSBhbmQgdHlwZQ0KcmVtb3ZlLiZu YnNwOyBCZSANCnN1cmUgdG8gaW5jbHVkZSB0aGUgZS1tYWlsIGFkZHJlc3MgeW91IHdvdWxkIGxp a2UgcmVtb3ZlZCBmcm9tIG91ciANCmxpc3QuPC9GT05UPjwvUD4NCjxQIGFsaWduPXJpZ2h0Pjwv UD4NCjxQIGFsaWduPXJpZ2h0PiZuYnNwOzwvUD4NCjxQIGFsaWduPXJpZ2h0PiZuYnNwOzwvUD4N CjxQIGFsaWduPWNlbnRlcj48L1A+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDAw MCBzaXplPTI+DQo8UCBhbGlnbj1jZW50ZXI+Jm5ic3A7PC9QPjwvRk9OVD48L0RJVj48L0JPRFk+ PC9IVE1MPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KZW51bSBtYWlsaW5nIGxpc3QNCmVudW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2VudW0NCg== --0__=oONluuei1FrCiP8ey410bHifN1i7hu38wRcivMzHVz7t9GLCfgMCrvab Content-type: text/plain; charset=us-ascii Content-Disposition: inline Esperamos su visita en: Web corporativa: http://www.telefonica-data.es Revista Pulso On Line: http://www.telefonica-data.es/pulso T.I.C: http://www.tdatacenter.com/es Este mensaje se dirige exclusivamente a su destinatario y puede contener informacion privilegiada o confidencial cuya divulgacion esta prohibida en virtud de la legislacion vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma via y proceda a su destruccion. --0__=oONluuei1FrCiP8ey410bHifN1i7hu38wRcivMzHVz7t9GLCfgMCrvab-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Feb 5 21:42:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29496 for ; Tue, 5 Feb 2002 21:42:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA18848 for enum-archive@odin.ietf.org; Tue, 5 Feb 2002 21:42:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18311; Tue, 5 Feb 2002 21:33:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18282 for ; Tue, 5 Feb 2002 21:33:11 -0500 (EST) Received: from ps.pxserver.com ([202.164.189.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28245 for ; Tue, 5 Feb 2002 21:33:02 -0500 (EST) Received: from localhost ([202.164.189.225]) by ps.pxserver.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 10:39:17 +0800 X-Sender: johnx3001@yahoo.com From: John M To: enum@ietf.org Date: Wed, 06 Feb 2002 10:39:17 +0800 Reply-To: johnx3002@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 06 Feb 2002 02:39:17.0305 (UTC) FILETIME=[78DC8290:01C1AEB7] Content-Transfer-Encoding: 7bit Subject: [Enum] JOIN FOR FREE! ... Learn and Earn Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Hello Fellow Networker, My name is John Miranda. I am now focusing on one online opportunity. I have tried several of these online opportunities full of hype promising us thousands of dollars every month. It is a sad fact that many people who are in need to earn additional income is being victimized by this fly by night scam artists. Every time I tried one opportunity after the other, I ended more broke than ever. As a result of trying all these opportunities, I have decided to select on my portfolio the company which is true to their words. Not the one full of hype. The only one that has consistently sent me the monthly check. Even without the hype they have given me the best compensation plan with their high % commission. They are providing real service not the one that simply transfer wealth from the new signups to the people at the top of the pyramid. They are not a form of a pyramid scam. Also when you join, you will have a team of upline sponsors who will help you succeed every step of the way. Instead of being left alone, you will be guided step by step by real people, not those autoresponders. Do not believe in do nothing, no recruiting, no selling schemes. They are scams. You might want to try it to prove my words. Only you can make your own success together with the help of your sponsors. If you have 2 to 3 hours a day, you will be able to earn a full income in a few months. And there is absolutely no limit as how much you can earn. It is designed to gain momentum after some time. But I prefer to avoid such statements as "You will get rich". I read it everywhere and I do not want to sound like them. To get your FREE membership ID send email to johnx300@yahoo.com and put "REGISTER ME FOR FREE" in the subject and your fullname in the body of your email. Regards, John Miranda johnx300@yahoo.com Note: You don't need to request for removal. This is a one time email. Your email address will be automatically de-activated in our list if you don't reply in this mail. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Feb 5 21:54:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29801 for ; Tue, 5 Feb 2002 21:54:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA19857 for enum-archive@odin.ietf.org; Tue, 5 Feb 2002 21:54:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19175; Tue, 5 Feb 2002 21:45:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19126 for ; Tue, 5 Feb 2002 21:45:26 -0500 (EST) Received: from dan ([211.100.89.77]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29559 for ; Tue, 5 Feb 2002 21:45:19 -0500 (EST) Message-Id: <200202060245.VAA29559@ietf.org> From: "T&F Information Exchange" To: Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Date: Wed, 6 Feb 2002 10:44:56 Subject: [Enum] A professional company providing credit & status report of Chinese company. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A professional company providing credit & status report of Chinese company. Dear Sirs, T&F is a senior investigative corporation providing credit & status report of Chinese companies for global clients. If you are in need of data from China, we are available to provide that information on consignment. We are an established authority in the field of research and information gathering in China. At the same time, we can also consign investigative missions to you when we need data from your country. In this manner we would hope to achieve a mutually beneficial arrangement exchanging needed information on a regular basis. Our services include: 1/ Credit and status investigations, including: Registration; corporate history; corporate structure; background of legal person and executives; financial profiles; banking relationships; operating situation; staff; products; facilities; profiles of affiliates; and more. 2/ professional market research, including: Advertising effectiveness; new product market research; and more. 3/ Investment services: Investment feasibility analyses; business partners' credit and status reports; agenting for foreign companies; comprehensive inquiry services; and more. 4/ Information protection: Inquiries on trademark and patent registration in China; knowledge property protection; trademark investigation in cases of trademark imitation; more. 5/ Information collection: Information about enterprises within China; information collection on policies, laws, current and historical business trends; and open profiles of various enterprises. 6/ Legal consultation: All-around legal consultation services for both enterprises and individuals. 7/ Criminal record searches. T&F has built a large number of stable cooperative relationships with many governmental departments in China. For example, we have made successful arrangements with the Industry & Trade Administrative Bureau of China, China Statistics Bureau, China National Economic Information Center, etc. The large investigative network of T&F is made up of many economic specialists and professional investigators. We are interested in any opportunity of information exchanging. If our investigative abillities might be of assistance,please contact us. Awaiting your reply. T&F Information Exchange (T&F) Physical Address : Room 210, Building 2, Chegongzhuang Street No. 6, Xicheng District, Beijing, China Post Code: 100044 Tel: +86-10-6800-3112 Fax: +86-10-6800-1452 Web site: http://www.tangfeng.org E-mail: business1@tangfeng.org business2@tangfeng.org xiuyuan@tangfeng.org We are very apologized for the inconvenience arisen from this letter to you. Your name will be removed from our maillist upon requirement. Thank you. 賈痰섐槿錟숭횐랙，轟伎繫법錟숭륩蛟포，殮댐뚤렘錟芎，醵똑없뚤寧직！ 苟潼貢囹：http://love2net.51.net/，뫘뜩출롤돨낚욉흡숭된콱윱苟∼∼ ---------------------------------------------------- INFORMATION This message has been sent using a trial-run version of the TSmtpRelayServer Delphi Component. ---------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Feb 6 00:23:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03737 for ; Wed, 6 Feb 2002 00:23:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA27067 for enum-archive@odin.ietf.org; Wed, 6 Feb 2002 00:23:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26498; Wed, 6 Feb 2002 00:12:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26468 for ; Wed, 6 Feb 2002 00:12:50 -0500 (EST) Received: from roam.psg.com (root@host1.stucall.u-net.com [195.102.66.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03557 for ; Wed, 6 Feb 2002 00:12:48 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16YKO0-0000SM-00 for enum@ietf.org; Wed, 06 Feb 2002 05:12:48 +0000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: enum@ietf.org Subject: Re: [Enum] JOIN FOR FREE! ... Learn and Earn References: Message-Id: Date: Wed, 06 Feb 2002 05:12:48 +0000 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit this list still allows spammers to post, how pleasant. randy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 6 05:38:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16053 for ; Wed, 6 Feb 2002 05:38:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA21948 for enum-archive@odin.ietf.org; Wed, 6 Feb 2002 05:38:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21082; Wed, 6 Feb 2002 05:28:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21051 for ; Wed, 6 Feb 2002 05:28:43 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15897 for ; Wed, 6 Feb 2002 05:28:39 -0500 (EST) Received: from [0.0.0.0] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA26155; Wed, 6 Feb 2002 11:28:06 +0100 (MET) Date: Wed, 06 Feb 2002 09:53:06 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Randy Bush , enum@ietf.org Subject: Re: [Enum] JOIN FOR FREE! ... Learn and Earn Message-ID: <4450414.1012989186@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-06 05.12 +0000 Randy Bush wrote: > this list still allows spammers to post, how pleasant. We don't have much other traffic, so it makes one know the list is still alive, and that one is still subscribed ;-) paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 6 05:55:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16432 for ; Wed, 6 Feb 2002 05:55:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA23309 for enum-archive@odin.ietf.org; Wed, 6 Feb 2002 05:55:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22489; Wed, 6 Feb 2002 05:46:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22460 for ; Wed, 6 Feb 2002 05:46:55 -0500 (EST) Received: from redstorm.unimessage.net (redstorm.unimessage.net [212.6.90.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16236 for ; Wed, 6 Feb 2002 05:46:50 -0500 (EST) From: steinle@smartvia.de Received: from mouse.unimessage.net (root@mouse.unimessage.net [212.6.90.252]) by redstorm.unimessage.net (8.10.2/8.10.2) with ESMTP id g16AirK26448; Wed, 6 Feb 2002 11:44:53 +0100 (MET) Date: Wed, 6 Feb 2002 11:44:53 +0100 (MET) Message-ID: <1454699336.1012992379216.JavaMail.root@mouse.unimessage.net> To: paf@cisco.com, randy@psg.com, enum@ietf.org Subject: Re: [Enum] JOIN FOR FREE! ... Learn and Earn In-Reply-To: <4450414.1012989186@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Canbox-Sender: steinle@smartvia.de X-Canbox-MsgType: email X-Canbox-SendDate: 1012992324776 X-Canbox-UserName: steinle X-Canbox-ServiceGroup: smartvia Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > --On 2002-02-06 05.12 +0000 Randy Bush wrote: > > this list still allows spammers to post, how pleasant. > We don't have much other traffic, so it makes one know the list is still > alive, and that one is still subscribed ;-) > paf lol If that is desired...I can help you. Please visit my registries ( http://nic.pro.xs2.net and http://nic.info.xs2.net ) and my my pleasure shop: http://www.adult.shop.new.net . havr fun! ;-) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 6 12:25:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26325 for ; Wed, 6 Feb 2002 12:25:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15667 for enum-archive@odin.ietf.org; Wed, 6 Feb 2002 12:25:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15038; Wed, 6 Feb 2002 12:14:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15008 for ; Wed, 6 Feb 2002 12:14:05 -0500 (EST) Received: from spitfire.toycar.net (root@host-19.overdrive.com [198.88.160.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25966 for ; Wed, 6 Feb 2002 12:14:00 -0500 (EST) Received: from mail.overdrive.com (host-6.overdrive.com [198.88.160.6]) by spitfire.toycar.net (8.9.3/8s9s3) with ESMTP id MAA18802 for ; Wed, 6 Feb 2002 12:14:04 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [Enum] JOIN FOR FREE! ... Learn and Earn X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Wed, 6 Feb 2002 12:13:47 -0500 Message-ID: Thread-Topic: Re: [Enum] JOIN FOR FREE! ... Learn and Earn Thread-Index: AcGvMaNhxA/xpUQmTlatV7XpeGBIvw== From: "Ray Fassett" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA15010 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I'll play too.... http://www.enum.info no erotica though, will have to work on that angle. Of course, if you happen to see anything contained that is not quite correct, I would be highly appreciative to change it. Mr. Shockey, for example, may not like the use of the term "application" in the heading, in fact I do plan to change this to the word "utility". ok, no more spamming from me (for today). Ray _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 7 03:15:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22306 for ; Thu, 7 Feb 2002 03:15:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA06063 for enum-archive@odin.ietf.org; Thu, 7 Feb 2002 03:15:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04567; Thu, 7 Feb 2002 02:59:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04470 for ; Thu, 7 Feb 2002 02:59:33 -0500 (EST) Received: from chollian.net (s210-221-76-10.thrunet.ne.kr [210.221.76.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22044 for ; Thu, 7 Feb 2002 02:58:20 -0500 (EST) Message-Id: <200202070758.CAA22044@ietf.org> Reply-To: lee8153@chollian.net From: 최진희 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 7 Feb 2002 17:02:29 +0900 X-User: 2.62-hkilfmlu-hlpnip-Ffkik Subject: [Enum] 칼라레이져/컴퓨터/화면100인치<급처분> 홍 ' 보* Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org
문서번호:21가마-008977
수 신:대표이사님
발 신:사무기관리조합 최진범
참 조:컴퓨터/복사기/사무기/LCD/부동산 처분건
◈ 안녕하십니까? 사무기관리조합입니다.중소기업협참조로 연락드리오니 회사및
직원분들이 필요하시면 참조하시기 바랍니다.(대리점 정리하는 사무기 처분건입니다)
◈ 저희 사무기관리조합은 사무기기 대리점관리 및 대리점 정리시 사무기기를 일시적으로
처분하여 드리며 본 공문처분가격은 일시적인 처분가격 입니다.
 LCD(두께2cm)모니터19인치 무료상기물품 구입자만 무료임
(화면 100인치포함)모든제품 보증서 포함됨
★LCD빔프로젝터+레이져칼라프린터구입가격 1,600만원→처분가격285만
(프로젝터와 +칼라레이져는 세트입니다 각각 분리구입은 불가능함)
(소니,산요,샤프,엡손,HP 메이커별로 여러가지가 있음 가격은 무조건 285만원임)
◐ 구입은 현금및 자기앞 수표만 가능하며
세금계산서는 의무적으로 발행하여드림
◐컴퓨터/복사기/팩스/키폰/사무기7가지세트용
☞7가지원 소비자가격1,200만원⇒처분가격385만원
*****************************************************************
①복사기(축소,확대,줌 배율기능)+②삼성컴퓨터(686 DVD내장형/정품프로그램CD10종류외
* 화상카메라/*고성능 마이크포함) +③프린터초고속+④스캐너+⑤일반용지 팩시밀리
⑥키폰 LG디지탈16국선+⑦LCD모니터 19인치 (반드시 7가지를 1세트로 구입하셔야함)
★ 상기 모든 제품은 박스도 풀지 않은 신품 입니다(전제품무상A/S보증서 포함임)
★7가지원 소비자가격1,200만원→7가지 세트 처분가격:385만원(현금및자기앞수표만가능)
★7가지를 세트로 만 구입 하셔야 하며 낱개는 구입불가함(예,컴퓨터만은구입불가) 
****************************************************************
$$상기 7가지 제품은 여러세트가 있으니 창고에서 보시고 유리하신것으로 선택바람
★-- 대표이사님이 직접 방문 상기사무기기만 구입할경우는 중소기업
대표자 예우차원에서 10%할인하여드림(직원은 절대 할인불가함)
◐부동산 처분건 -서서울에서 30분거리 서해대교도로변 땅급매건
★ 주의사항★사장님이직접방문 구입할 경우 중소기업 대표자 예우차원에서 10%할인
1-상기 모든제품은 박스도 풀지않은 신품입니다(전제품 무상보증서 포함되어있음)
2-(대표자)결정권자가 직접방문 구입하셔야합니다.모든제품은 (부가세 별도)입니다..
3-상부에 결제 또는 보고를 드려야 하는 직원은 출입을 금합니다.
4-자세한 제품사양 및 모델은 전화상의로 문의할수없고 창고로 직접 방문하셔서
보시고 만족하시면 즉시 구입하시기 바랍니다.(세금계산서는의무적으로발행하여 드림)
5-모든제품이(박스도 풀지않는제품)이지만 LCD모니터19"형만은중고인관계로 무료로드림
6-LCD빔프로젝터+레이져칼라프린터는 중고제품이며사장님이 방문구입바랍니다
7-반드시 구입하실 날짜에 방문 하셔서 직접 보시고 그자리에서 (금액을 완불바람)
8-사장님이직접방문 구입할 경우 중소기업 대표자 예우차원에서 10%할인하여드림
필히 본 공문과 사업자등록증 사본, 신분증을 가지고 방문 (상기물품만 10%할인함)
☞업무시간:오전9시30분부터~오후6시까지(토요일은 쉽니다)
☞ 주 차:1층에서 5층까지1톤화물차까지 편리함 (구입영수증이 있어야무료임)
☎(02)761-1407     FAX(02)783-2058- FAX(02)-784-5766
☞혼자서만 보시지마시고 신규 사장님에게도 알려 주시기 바랍니다
☞주차- 한빛은행건물(하늘색) 지하 5층까지임 구입영수증이 있어야 무료임
63빌딩바로 옆건물 한빛은행9층 사무기관리조합 안내실로방문
사   무   기   관   리   조   합
본 메일은 인터넷 상에서 수집된것이며 메일 주소 이외에 어떠한 개인정보도 알수없습니다 본메일은 두번다시 발송 않합니다
수신거부는여기를 클릭해주세요
_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 7 05:02:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24001 for ; Thu, 7 Feb 2002 05:02:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA11886 for enum-archive@odin.ietf.org; Thu, 7 Feb 2002 05:02:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10893; Thu, 7 Feb 2002 04:46:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10862 for ; Thu, 7 Feb 2002 04:46:41 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23580 for ; Thu, 7 Feb 2002 04:46:38 -0500 (EST) Received: from [0.0.0.0] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA01262 for ; Thu, 7 Feb 2002 10:46:09 +0100 (MET) Date: Thu, 07 Feb 2002 10:05:18 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org Message-ID: <6394205.1013076318@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Enum] Update of RFC 2916 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit I hereby request input on what to change in RFC 2916. Please keep the subject on the mail you either send to the list, or to me privately. One week from today, next thursday, I will collect all requests and summarize them on this list. Regards, paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 7 05:36:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24344 for ; Thu, 7 Feb 2002 05:36:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA13315 for enum-archive@odin.ietf.org; Thu, 7 Feb 2002 05:36:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12527; Thu, 7 Feb 2002 05:24:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12490 for ; Thu, 7 Feb 2002 05:24:40 -0500 (EST) Received: from localhost ([211.215.45.107]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24242 for ; Thu, 7 Feb 2002 05:24:36 -0500 (EST) Message-Id: <200202071024.FAA24242@ietf.org> Reply-To: mallbank@mallbank.co.kr From: mallbank To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 7 Feb 2002 19:24:53 +0900 Subject: [Enum] [광고]쇼핑몰 구축..망설이지마세요! 몰뱅크입니다. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org 몰뱅크 쇼핑몰

이 정보가 필요하시지 않은 분께는 허락없이 보낸점에 대해서 양해를 구합니다.
본 메일 데이터는 공개적인 곳에서  취득한 것으로 메일이외에 개인정보는 없습니다.
[수신거부]를 누르시면 다음부터는 메일이 가지 않게 됩니다.
또한 광고라는 글을 밝힌 이메일은 스팸으로부터 걸려지오니 메일부가기능에 설정하시면 이와 비슷한 부류의 메일은 피하실수 있습니다.

몰뱅크에서는 새로운 쇼핑몰솔루션을 개발하여 저렴하게 제공하고자 합니다.

쇼핑몰의 주요특징

- 상품분류 관리 및 쉬운 상품등록
- 암호화를 통한 안전한 결재시스템
- 고객관리 시스템 탑재
-  인기상품, 우수고객 관리
- 고객방문로그 및 회원전체메일 기능
- 간편한 조작으로 쇼핑몰 환경변경 가능
- 게시판 자동생성 기능 (원하는 수만큼)
- 세션을 이용하여 보안에 치중

보다 자세한 내용은 홈페이지에 있습니다.
자신있게 다른 솔루션과 비교할 수 있습니다.

 

_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 7 10:09:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29367 for ; Thu, 7 Feb 2002 10:09:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24966 for enum-archive@odin.ietf.org; Thu, 7 Feb 2002 10:09:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24135; Thu, 7 Feb 2002 09:59:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24104 for ; Thu, 7 Feb 2002 09:59:22 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29023 for ; Thu, 7 Feb 2002 09:59:20 -0500 (EST) Received: from [0.0.0.0] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA26727 for ; Thu, 7 Feb 2002 15:58:50 +0100 (MET) Date: Thu, 07 Feb 2002 15:54:27 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org Subject: Re: [Enum] Update of RFC 2916 Message-ID: <7651136.1013097267@localhost> In-Reply-To: <6394205.1013076318@localhost> References: <6394205.1013076318@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA24105 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit --On 2002-02-07 10.05 +0100 Patrik F�ltstr�m wrote: > I hereby request input on what to change in RFC 2916. Please keep the > subject on the mail you either send to the list, or to me privately. > > One week from today, next thursday, I will collect all requests and > summarize them on this list. A clearification: In my mind, I have the following issues: (1) Correction of typos (2) Alignment with the DDDS documents which replace RFC 2915 (3) Additional clearification about the use of flags when selecting the correct NAPTR RR I just want as editor have all issues now (or never) and then "kill" them or update the document for one issue at a time. I am _not_ reopening the whole ENUM issue for discussion again. We update the RFC...not reinvent what is done. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 9 12:35:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18112 for ; Sat, 9 Feb 2002 12:35:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26404 for enum-archive@odin.ietf.org; Sat, 9 Feb 2002 12:35:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25678; Sat, 9 Feb 2002 12:25:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25575 for ; Sat, 9 Feb 2002 12:25:46 -0500 (EST) Received: from t-0n045voi2os9b ([202.99.47.134]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17637 for ; Sat, 9 Feb 2002 12:25:39 -0500 (EST) Message-Id: <200202091725.MAA17637@ietf.org> From: "T&F" To: Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Date: Sun, 10 Feb 2002 01:25:11 Subject: [Enum] A professional company providing credit&status report of Chinese company Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A professional company providing credit & status report of Chinese company. Dear Sirs, T&F is a senior investigative corporation providing credit & status report of Chinese companies for global clients. If you are in need of data from China, we are available to provide that information on consignment. We are an established authority in the field of research and information gathering in China. At the same time, we can also consign investigative missions to you when we need data from your country. In this manner we would hope to achieve a mutually beneficial arrangement exchanging needed information on a regular basis. Our services include: 1/ Credit and status investigations, including: Registration; corporate history; corporate structure; background of legal person and executives; financial profiles; banking relationships; operating situation; staff; products; facilities; profiles of affiliates; and more. 2/ professional market research, including: Advertising effectiveness; new product market research; and more. 3/ Investment services: Investment feasibility analyses; business partners' credit and status reports; agenting for foreign companies; comprehensive inquiry services; and more. 4/ Information protection: Inquiries on trademark and patent registration in China; knowledge property protection; trademark investigation in cases of trademark imitation; more. 5/ Information collection: Information about enterprises within China; information collection on policies, laws, current and historical business trends; and open profiles of various enterprises. 6/ Legal consultation: All-around legal consultation services for both enterprises and individuals. 7/ Criminal record searches. T&F has built a large number of stable cooperative relationships with many governmental departments in China. For example, we have made successful arrangements with the Industry & Trade Administrative Bureau of China, China Statistics Bureau, China National Economic Information Center, etc. The large investigative network of T&F is made up of many economic specialists and professional investigators. We are interested in any opportunity of information exchanging. If our investigative abillities might be of assistance,please contact us. Awaiting your reply. T&F China 賈痰섐槿錟숭횐랙，轟伎繫법錟숭륩蛟포，殮댐뚤렘錟芎，醵똑없뚤寧직！ 苟潼貢囹：http://love2net.51.net/，뫘뜩출롤돨낚욉흡숭된콱윱苟∼∼ ---------------------------------------------------- INFORMATION This message has been sent using a trial-run version of the TSmtpRelayServer Delphi Component. ---------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 9 13:09:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18403 for ; Sat, 9 Feb 2002 13:09:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27646 for enum-archive@odin.ietf.org; Sat, 9 Feb 2002 13:09:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27167; Sat, 9 Feb 2002 13:00:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27128 for ; Sat, 9 Feb 2002 13:00:39 -0500 (EST) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18294 for ; Sat, 9 Feb 2002 13:00:36 -0500 (EST) Received: from user-2ivekjm.dialup.mindspring.com ([165.247.82.118] helo=dick.ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16Zbnh-0007FT-00 for enum@ietf.org; Sat, 09 Feb 2002 13:00:38 -0500 Message-Id: <5.1.0.14.2.20020209125501.043ed5d0@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 09 Feb 2002 12:55:31 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: Internet-Draft Cutoff Dates for Minneapolis, MN Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a reminder for those of you interested in presenting.... >To: IETF-Announce: ; >From: Internet-Drafts Administrator >Subject: Internet-Draft Cutoff Dates for Minneapolis, MN >Date: Fri, 08 Feb 2002 14:54:45 -0500 >Sender: nsyracus@cnri.reston.va.us > > >NOTE: There are two (2) Internet-Draft Cutoff dates > >February 22nd: Cutoff for Initial Submissions (new documents) > >All initial submissions(-00) must be submitted by Friday, >February 22nd, 17:00 US-EST. Initial submissions received after this time >will NOT be made available in the Internet-Drafts directory, and will have >to be resubmitted. > >As before, all initial submissions (-00.txt) with a filename beginning >with a draft-ietf MUST be approved by the appropriate WG Chair prior to >processing and announcing. WG Chair approval must be received by >Monday, February 25th. > >Please do NOT wait until the last minute to submit. > >Be advised: NO placeholders. Updates to initial submissions received > the week of February 22nd will NOT be accepted. > >March 1st: FINAL Internet-Draft Cutoff > >All revised Internet-Draft submissions must be submitted by Friday, >March 1st, 2002 at 17:00 US-EST. Internet-Drafts received after this time >will NOT be announced NOR made available in the Internet-Drafts >Directories. > >We will begin accepting Internet-Draft submissions the week of the >meeting, though announcements will NOT be sent until the IETF meeting >is over. > >Thank you for your understanding and cooperation. Please do not hesitate >to contact us if you have any questions or concenrs. > >FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_53.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 9 13:27:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18636 for ; Sat, 9 Feb 2002 13:27:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28336 for enum-archive@odin.ietf.org; Sat, 9 Feb 2002 13:27:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28047; Sat, 9 Feb 2002 13:18:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28016 for ; Sat, 9 Feb 2002 13:18:28 -0500 (EST) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18526 for ; Sat, 9 Feb 2002 13:18:25 -0500 (EST) Received: from user-2ivekjm.dialup.mindspring.com ([165.247.82.118] helo=dick.ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16Zc4v-0001jK-00 for enum@ietf.org; Sat, 09 Feb 2002 13:18:26 -0500 Message-Id: <5.1.0.14.2.20020209131823.046d7c68@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 09 Feb 2002 13:19:01 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] The revised ENUM Charter has been approved by the IESG Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org http://www.ietf.org/html.charters/enum-charter.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 10 19:42:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12660 for ; Sun, 10 Feb 2002 19:42:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA00565 for enum-archive@odin.ietf.org; Sun, 10 Feb 2002 19:42:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00216; Sun, 10 Feb 2002 19:31:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00109 for ; Sun, 10 Feb 2002 19:30:57 -0500 (EST) Received: from huamin ([61.241.122.146]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12447 for ; Sun, 10 Feb 2002 19:30:53 -0500 (EST) Message-Id: <200202110030.TAA12447@ietf.org> From: "�S酌큑�" To: Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Date: Mon, 11 Feb 2002 08:31:14 Subject: [Enum] 뼝女뵀쯤욋못퀭격쾨，龍퀭쯩쾨쯩돕냥묘！ Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org 吝쓴돨邱��/큽却： 퀭봤！ 흔벎�@룐斤緞�뫓식骸캣ㅧ嘆Щ畛속쳅愷骸휈r�g，�댡鄕♠큵h뇜。谿븈�齋潛t雷。 흔벎퀭콘녜놔寧�c븈�g곹죄썩，옵賈퀭뵨퀭돨폐쁈�_돕냥묘돨�뵹鶯� 《�S�벻뼱a롮》鈴제異쉔접홍뉦묏�鉗�쁈섟��뺷섴�P뉶�w돨샘굶뵷볽�Y죕롮，뇜죄114�듩뮧宇꺏캣┙復�棍，��唐페劍뫘뜩돨륩꾎흔：녞貫�듩뮧宇깳¡a틔륩꾎�P�I俚、契쁈롸�맮황宇꺬獨걱齷桓歡碩켬寢돈�꾎。 《�S�벻뼱a롮》야唐룋댕돨슥빳昑뵨긱적우쌥돨景昑，角寧��충蕨폐쁈갞鹿"例콘꿴��"욇寮뙢돨�듮唐턴∑宇꺠신_。 《�S�벻뼱a롮》角寧��譚홍뉦몹伽�S�벻뼱a롮폦냥돨푐籃횐�w，첼��伽돨�S�벻뼱a롮棠角鹿뒈�^�S�벻뼱a롮욇첍접퐲쟅뙡獗돨혫북�w，홍뉦�S�벻뼱a롮야唐룋댕돨斤口鎧섞휽斤口퐺북돨콘제。 《�S�벻뼱a롮》鑒푤소폐慤撚데貫斤口된콱꿴璂，谿珂瓊묩폐撚되쩍 http://www.china168.com 《 뻑短속촉뼝女뵀쯤욋貢쭹젬촉 》 龍劤쾨우샆，�f慤흔雷！ 賈痰섐槿錟숭횐랙，轟伎繫법錟숭륩蛟포，殮댐뚤렘錟芎，醵똑없뚤寧직！ 苟潼貢囹：http://love2net.51.net/，뫘뜩출롤돨낚욉흡숭된콱윱苟∼∼ ---------------------------------------------------- INFORMATION This message has been sent using a trial-run version of the TSmtpRelayServer Delphi Component. ---------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Feb 11 05:31:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27835 for ; Mon, 11 Feb 2002 05:31:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA29238 for enum-archive@odin.ietf.org; Mon, 11 Feb 2002 05:31:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28411; Mon, 11 Feb 2002 05:22:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28382 for ; Mon, 11 Feb 2002 05:22:15 -0500 (EST) Received: from mail1.itu.ch (mail1.itu.ch [156.106.192.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27704 for ; Mon, 11 Feb 2002 05:22:10 -0500 (EST) Received: by mail1.itu.ch with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Feb 2002 11:21:40 +0100 Message-ID: <49ED700A32CFD511B72900508B959DFEB6E7C2@mailsrv4.itu.ch> From: "Shaw, Robert" To: enum@ietf.org Date: Mon, 11 Feb 2002 11:06:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] ITU ENUM Workshop on February 8, 2002 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Materials and presentations related to the ITU tutorial workshop held on 8 February 2002 on ENUM can be found at: http://www.itu.int/ITU-T/worksem/enum/ Bob -- Robert Shaw ITU Internet Strategy and Policy Advisor International Telecommunication Union Place des Nations, 1211 Geneva, Switzerland _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Feb 11 07:07:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28871 for ; Mon, 11 Feb 2002 07:07:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03898 for enum-archive@odin.ietf.org; Mon, 11 Feb 2002 07:07:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03105; Mon, 11 Feb 2002 06:56:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03060 for ; Mon, 11 Feb 2002 06:56:46 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28724; Mon, 11 Feb 2002 06:56:44 -0500 (EST) Message-Id: <200202111156.GAA28724@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 11 Feb 2002 06:56:44 -0500 Subject: [Enum] I-D ACTION:draft-ietf-sipping-e164-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Using ENUM for SIP Applications Author(s) : J. Peterson, H. Liu, J. Yu, B. Campbell Filename : draft-ietf-sipping-e164-01.txt Pages : 35 Date : 08-Feb-02 Although SIP was clearly one of the primary applications for which ENUM was created, there is nevertheless widespread uncertainty about the demarcation of SIP location services from ENUM. This document attempts to sharpen the distinction between location services provided by the two protocols, illustrating how the two protocols might work in concert and clarifying the authoring and processing of ENUM records for SIP applications A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sipping-e164-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-e164-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020208130646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-e164-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-e164-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020208130646.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Feb 11 10:36:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06018 for ; Mon, 11 Feb 2002 10:36:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14556 for enum-archive@odin.ietf.org; Mon, 11 Feb 2002 10:36:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13561; Mon, 11 Feb 2002 10:25:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13530 for ; Mon, 11 Feb 2002 10:25:23 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05481 for ; Mon, 11 Feb 2002 10:25:21 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1BFPMb20447 for ; Mon, 11 Feb 2002 10:25:22 -0500 Message-Id: <5.1.0.14.2.20020211102258.029f4910@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Feb 2002 10:25:22 -0500 To: enum@ietf.org From: Richard Shockey Subject: Fwd: [Enum] I-D ACTION:draft-ietf-sipping-e164-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Though this draft is going into the SIPPING WG we've had a discussion with the Chairs of that WG and there is no problem discussing the issue here. SIPPING has a huge plate of work so we see no real conflicts. >To: IETF-Announce: ; >CC: enum@ietf.org >Cc: sipping@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Date: Mon, 11 Feb 2002 06:56:44 -0500 >Subject: [Enum] I-D ACTION:draft-ietf-sipping-e164-01.txt >Sender: enum-admin@ietf.org >X-Mailman-Version: 1.0 >List-Id: Enum Discussion List >X-BeenThere: enum@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Session Initiation Proposal Investigation >Working Group of the IETF. > > Title : Using ENUM for SIP Applications > Author(s) : J. Peterson, H. Liu, J. Yu, B. Campbell > Filename : draft-ietf-sipping-e164-01.txt > Pages : 35 > Date : 08-Feb-02 > >Although SIP was clearly one of the primary applications for which >ENUM was created, there is nevertheless widespread uncertainty about >the demarcation of SIP location services from ENUM. This document >attempts to sharpen the distinction between location services >provided by the two protocols, illustrating how the two protocols >might work in concert and clarifying the authoring and processing of >ENUM records for SIP applications > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-01.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-sipping-e164-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sipping-e164-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20020208130646.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sipping-e164-01.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 12 11:50:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18121 for ; Tue, 12 Feb 2002 11:50:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01608 for enum-archive@odin.ietf.org; Tue, 12 Feb 2002 11:50:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01164; Tue, 12 Feb 2002 11:40:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01139 for ; Tue, 12 Feb 2002 11:40:23 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17705 for ; Tue, 12 Feb 2002 11:40:19 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA11289 for ; Tue, 12 Feb 2002 17:40:18 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA09983 for ; Tue, 12 Feb 2002 17:40:16 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id <1ZZHKZ61>; Tue, 12 Feb 2002 17:40:19 +0100 Message-ID: From: Brandner Rudolf To: enum@ietf.org Date: Tue, 12 Feb 2002 17:40:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Enum] Backward compatibility Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi folks, let's assume that an end system (or terminal) sends out a DNS request with a NAPTR in it and this request hits an intermediate node still running an old version of BIND (i.e. BIND 5). What will happen with that request? Best Regards, Rudi Rudolf Brandner Siemens ICN M SR 1 +49-89-72251003 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 13 03:17:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22858 for ; Wed, 13 Feb 2002 03:17:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA20165 for enum-archive@odin.ietf.org; Wed, 13 Feb 2002 03:17:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19850; Wed, 13 Feb 2002 03:07:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19818 for ; Wed, 13 Feb 2002 03:07:56 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22572 for ; Wed, 13 Feb 2002 03:07:53 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA04773; Wed, 13 Feb 2002 09:07:22 +0100 (MET) Date: Wed, 13 Feb 2002 09:00:48 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Brandner Rudolf , enum@ietf.org Subject: Re: [Enum] Backward compatibility Message-ID: <5407057.1013590848@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-12 17.40 +0100 Brandner Rudolf wrote: > let's assume that an end system (or terminal) sends out a DNS request > with a NAPTR in it and this request hits an intermediate node still > running an old version of BIND (i.e. BIND 5). > > What will happen with that request? Executive summary: There will not be any problem. Detailed summary: You have two different issues here, and then another one hidden in the details: (a) Can an old version of for example BIND be primary/master server for NAPTR resource records? - A DNS server software can only be primary/master for resource record types which one can enter into the software. I.e. it have to do with managment and administration. (b) If you have a non-primary server, can it be a forwarding / caching only server for resource record types it does not understand? - Yes, a DNS program do according can handle DNS packets where the resource record type is unknown. And now the hidden one: (c) Can Bind (explicitly) before version 8 be secondary server for a zone which have unknown RR types? - No, because the secondary server caches the zone info on disk, and it can then not parse the output when it tries to read it after a reboot. Note 1: NAPTR was introduced for some time ago, so I even think some version 4 of Bind do handle NAPTR. Note 2: If you run a DNS software which is older than a year, you have other problems, namely security problems, regardless of who has written the software. Note 3: What is important to know is that the DNS specification itself makes it possible to handle unknown RR types. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 13 05:22:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25718 for ; Wed, 13 Feb 2002 05:22:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25270 for enum-archive@odin.ietf.org; Wed, 13 Feb 2002 05:22:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24949; Wed, 13 Feb 2002 05:12:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24917 for ; Wed, 13 Feb 2002 05:12:16 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25373 for ; Wed, 13 Feb 2002 05:12:11 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA09133; Wed, 13 Feb 2002 11:12:09 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA16632; Wed, 13 Feb 2002 11:12:07 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id <1ZZHLMTX>; Wed, 13 Feb 2002 11:12:11 +0100 Message-ID: From: Brandner Rudolf To: =?ISO-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: enum@ietf.org Subject: Re: [Enum] Backward compatibility Date: Wed, 13 Feb 2002 11:12:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA24918 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit This is very good. Thank you very much for that information and clarification. Rudi > -----Urspr�ngliche Nachricht----- > Von: Patrik F�ltstr�m [mailto:paf@cisco.com] > Gesendet: Mittwoch, 13. Februar 2002 09:01 > An: Brandner Rudolf; enum@ietf.org > Betreff: Re: [Enum] Backward compatibility > > > --On 2002-02-12 17.40 +0100 Brandner Rudolf > wrote: > > > let's assume that an end system (or terminal) sends out a > DNS request > > with a NAPTR in it and this request hits an intermediate node still > > running an old version of BIND (i.e. BIND 5). > > > > What will happen with that request? > > Executive summary: > > There will not be any problem. > > > Detailed summary: > > You have two different issues here, and then another one hidden in the > details: > > (a) Can an old version of for example BIND be primary/master > server for > NAPTR resource records? > > - A DNS server software can only be primary/master for resource record > types which one can enter into the software. I.e. it have to do with > managment and administration. > > (b) If you have a non-primary server, can it be a forwarding > / caching only > server for resource record types it does not understand? > > - Yes, a DNS program do according can handle DNS packets > where the resource > record type is unknown. > > > And now the hidden one: > > (c) Can Bind (explicitly) before version 8 be secondary > server for a zone > which have unknown RR types? > > - No, because the secondary server caches the zone info on > disk, and it can > then not parse the output when it tries to read it after a reboot. > > > Note 1: NAPTR was introduced for some time ago, so I even think some > version 4 of Bind do handle NAPTR. > > Note 2: If you run a DNS software which is older than a year, you have > other problems, namely security problems, regardless of who > has written the > software. > > Note 3: What is important to know is that the DNS specification itself > makes it possible to handle unknown RR types. > > paf > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 13 15:26:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19827 for ; Wed, 13 Feb 2002 15:26:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA29128 for enum-archive@odin.ietf.org; Wed, 13 Feb 2002 15:26:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28571; Wed, 13 Feb 2002 15:14:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28541 for ; Wed, 13 Feb 2002 15:14:41 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19554 for ; Wed, 13 Feb 2002 15:14:37 -0500 (EST) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062451; Wed, 13 Feb 2002 20:14:34 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: Date: Wed, 13 Feb 2002 20:14:34 +0000 To: Jon , Rudi From: Lawrence Conroy Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] sipping-e164 comments Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Folks, taking Richard at his word that ENUM is an appropriate place to discuss the sipping-enum document (and avoiding the wrath of Brian Rosen by not cross-posting), I have a few comments; these are not (to my knowledge) regulatory issues, so most of the group can resume its horizontal posture. First, I must say that I like this work. I'm not quite sure of the scope, and have some concerns that it is looking at the scenarios current for the use in public telecommunications systems only - i.e. it may have more to say than the purely technical. However, we need this in order to give information that is (correctly) lacking in 2915/2916. My comments are put inside square braces. From my reading of the draft:: -------------------------- It has a number of recommendations and disrecommendations. My initial scan of these comes up with: * Use SIP registration services to differentiate - NAPTR content should show address of record, not current contact address - Use a single SIP identity, and let the SIP system disambiguate between multiple concurrent contacts (e.g. work and home) [That's fine *for SIP* but may complicate and/or restrict the applicability of ENUM to reference only from IP-based devices. I can at least envisage ENUM being used to list my "steam" telephone for use from a hybrid (or non-IP based) telephone -- if only as part of a directory system. Using a SIP registration service may not be appropriate in all cases.] * SIP should be the service of choice. - Use 'SIP+E2U' rather than a putative 'TEL+E2U' service field - Use 'sip:' rather than 'tel:' scheme within 'SIP+E2U' service - If records including tel: URIs are present in the NAPTR resource record set, then they should be at a lower priority than 'pure' sip: URI. [Brave...(this risks SG16 jumping up & down on your collective heads :). The arguments for sip: and against tel: are well put. I'll duck the sip: versus h232: issue. However... There may be scenarios in which ENUM is used to identify a GSTN-connected device for use when dialing out from another GSTN-connected device. In such a scenario, indicating a sip: scheme may automatically direct the client to dial out to an MGC/MG combination, only for that to "bounce back" to the PSTN again. I may consider my SipPhone to be a different service from my "steam" phone, and I'm afraid to admit that the sip service pointing at the AoR known to the registrar with which my SipPhone is associated may not be listed as the highest order. Maybe in a year... Disambiguation using a single SIP AoR is a good idea IFF there is *a* SIP service provider with which I have (a) registration{s}. However, even if I do use SIP service, I may have more than one provider - I have more than one email account, and (even for SIP systems) the text in the draft reflects only one view of the future.] * Although NAPTRs use regexp, the examples in 2916 all use the "throw it away and replace with" form. This SHOULD be used. [Absolutely agree. One could argue that alternatives SHOULD NEVER be used, if only as they represent a nightmare for validation prior to populating the domain space, and can easily lead to unintended mappings. Fuzzy matching is useful for URN resolution, but fuzzy replacement is totally inappropriate for many other uses; not only the e164.arpa hierarchy.] * The contents of any tel: URI must not refer to the zone in which it is placed (i.e. there should not be a 'tight loop', with a phone number mapping to itself). [This is well put. There should be some specification for expected Client treatment of looping behaviour in ENUM queries, or in recursive recursive recursive ENUM queries on telephone numbers. However... I may want to indicate that this is a "final" telephone number, and that even though other records exist within the e164.arpa hierarchy for which I am authoritative, I do not wish this particular traversal to continue. An easy way of doing this is to force a tight loop. The expected client behaviour in this circumstance might be to use the current zone as the number to dial out. It's inelegant (and occupies space in the database) so perhaps enabling an "outer" recursion stopper in the ENUM system using a cleaner (and more compact) format is a candidate for the proposed update to RFC2916. Note that this deals with re-submission of tel: URIs to the ENUM hierarchy, and so does not affect RFC2915. A client MUST be ready to handle loops, not only this tight loop. For example, I might have two zones; one associated with my cell phone with the other associated with my work phone. Given the genius of our architects, the building in which I work has no cell phone coverage. Thus I have been known to forward calls to my cell phone to my work number. Also given that some people are unaware of the concept of time zones, I have been known to forward my work calls to my cell phone. Yes, I have forgotten and left a loop in place, notably on Monday morning. This is bound to happen within the ENUM system, so I'd suggest that there should be some text proposing expected behaviour in the face of such a loop. Whilst servers should be ready to handle such looping behaviour on the part of clients, it SHOULD be at least SHOULD strength on clients, and ideally such expanded text is a candidate for the RFC2916 update Patrik proposed.] * A general sip service should be used, not separate entries for different media types. Thus, a basic sip URI is MUCH preferred to separate entries specifying different media types (e.g. an entry for SIP+E2VOICE, with another for SIP+E2VIDEO). This argument extends to a disrecommendation of IM+E2U and PRES+E2U (or SIP+E2IM and SIP+E2PRES). [I am not happy completely with this proposal. Whilst I fully agree that partitioning entries for real-time media service with separate NAPTR records is not a good idea, there may well be a separation between real-time media service (using SIP), and non-real time service such as presence or IM -- I for one may not use the same service provider for my multimedia service and my "non-real-time" IM or presence service.] * DNS returns common (or public) information, and SIP can be used to avoid some of the privacy issues by requiring authentication. However, it may be a bad idea to put identifiable information into a SIP+E2U NAPTR record so may have unintended consequences. The DNS system will return this information to anyone sending the query and exhaustive search of the e.164.arpa space could easily extract it. [Very good point - if only as the ENUM server operators will be unamused at groups of people doing exhaustive queries of the domain space.] -------------------------- The draft also includes some limitations of ENUM, as described in RFC2916. This list is interesting, and seems to reflect the intended use of 2915 and 2916 for public telecommunications based resources. Thus: * Arbitrary strings are not used. [this is certainly true for the e164.arpa domain space.] * Private number spaces cannot be used. [Strictly, this is because ENUM as currently envisaged, operates using E.164 number space. I can use a full ENUM system that is unconnected with the rest of the world for my enterprise; I may not interconnect any private ENUM-like directory service with the public one and expect it to work. Does anyone use unregistered IP addresses within internal (unconnected) IP networks? Yes, it is a pain when migrating, but it happens.] * National (or origin-dependent) numbers cannot be used without conversion to E.164 number form. [ENUM operates using E.164 number space; I'm not sure that unqualified national (or local) numbers are within this space.] * Incomplete E.164 numbers cannot be indicated as such by ENUM [Actually, this is may be a parochial view; ENUM deals with a number space that "descends" from a global E.164 root. In some regions, there are variable length numbers, even within a given number block. It is perfectly possible to phone +498938450, or to phone +498938452525 -- one reaches the "pilot number" for the Munich Park Hilton whilst the other reaches the reservation desk. Although each of these, *in the current public telephone network* will be a leaf zone, this need not be the case for all future systems. Thus, a particular zone within a hierarchy akin to ENUM Tier1 might, in the future, include a NAPTR record referring to a "pilot number", as well as a set of sub-zones referring to extensions within an enterprise; a query may not be incomplete but target the parent zone within which an enterprise's DDI sub-zones are stored - this could result in a "pilot number" being returned. Whilst this would not be used in the current infrastructure, it is perfectly valid within the DNS (e.g. cnn.com returns a valid A record), and I'm not happy that we exclude this for all time - It's a GSTN limitation. As an aside, it's a goal to specify the operation of the currently envisaged public telecommunications ENUM system - that's one of the charter items for the IETF ENUM WG, I believe. Perhaps this text reflects that goal, in which case I wonder if it should be extracted and placed in another draft? Conversely, a particular number block within the ENUM hierarchy may have no NAPTR records but instead consist solely of NS records pointing to Tier2 leaf zone servers. The absence of such a NAPTR record should be indication to a client that either the authoritative server has no appropriate entry or that the query zone is a parant only (e.g. they have entered an incomplete number).] * The reason for E.164 prefix entries and expected behaviour on receipt of a query for them is not specified. [Strictly, it is perfectly valid to query within the e164.arpa domain space for a "non-leaf" zone. One can send a query for the NS resource record associated with a non-leaf zone (rather than the NAPTR), for example. Equally, one may query the SOA resource record for a parent zone. As suggested above, it may even be valid to have a NAPTR associated with a parent zone. Thus the comment that it is not meaningful to create records at non-leaf zones, or to send a query on such a zone (with an "incomplete" number) is too strong. They may be the exception within the normal operation of ENUM, but there may be valid reasons for entering the records and performing some queries on non-leaf zones.] -------------------------- best regards, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 14 10:49:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25046 for ; Thu, 14 Feb 2002 10:49:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05336 for enum-archive@odin.ietf.org; Thu, 14 Feb 2002 10:49:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04483; Thu, 14 Feb 2002 10:39:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04451 for ; Thu, 14 Feb 2002 10:39:51 -0500 (EST) Received: from lycos.com ([61.79.73.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24757 for ; Thu, 14 Feb 2002 10:39:39 -0500 (EST) Message-Id: <200202141539.KAA24757@ietf.org> Reply-To: guisee9@lycos.com From: 네트워크 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 15 Feb 2002 00:39:27 +0900 X-User: 2.62-figjdliv-lilkhn-Ddigq Subject: [Enum] [광고]손쉬운 사업및 부업을 소개합니다 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org

▶ 허락없이 홍보메일을 보내게 된 점 사과드립니다.
▶ 정보통신망이용촉진법규정을 준수하여 광고메일임을 표시하였읍니다.
▶ 전자우편주소는 인터넷상에서 취득하였으며, 전자우편주소외 어떠한 개인 정보도 가지고 있지 않습니다


!!!! 지금 이순간 님께서 저희 다이너스티를 만나신 것은 대단한 행운이라 확신합니다. !!!!

 

반갑습니다.
저는 부산에서 직장을 다니면서 부업으로 이 사업을 진행하고 있는 장강민이란 사람입니다.
적극적이고 열정적으로 살면서 자기 발전을 위해 끊임없이 노력하고 있습니다.

사업은 물론 만나서 대화를 나누어야 가장 좋겠지만, 우선 서면으로 대략을 알려드리니 살
펴보시고 계속 관심이 있으시면 연락주시기 바랍니다....

사업의 개념이 이해하기쉽고, 네트웤을 형성하는 방법이 on-line, off-line 으로 다양하고, 듣는 사람도 너무나 쉽게 납득할 수 있기 때문에 누구나 하실 수가 있습니다.

특히 기존에 어떤 형식이든 네트웤 마케팅을 하고 계시는 분들이면 더욱 잘 하실 수
있습니다.

이 사업은 통신 사업 중 가장먼저 시작된 새로운 사업으로서 다이너스티 라는 회사로 별정통신1호와 2호의 회사입니다.

자본 없이도 자기사업을 하는것과 같으며 시간이 흐름에 따라 점차 그 규모가 커져 1년 후 회원 수와 매출액면에서 비교가 안 될 정도로 확장되는 굉장히 비젼이 있는 사업입니다.

아마도 주변에서 아는분들이 다단계 사업을 하시면서 같이 사업해 보지 않겠냐는 제안 한 두 번쯤 안 들어보신 분들 거의없으리라 생각됩니다.

그렇지만 다단계가 뭡니까. 기존 시장의 유통구조를 바꾸어 즉 중간유통단계(총판, 대리점) 또는 광고없이 구전에 의한판매로 중간단계에서 발생되는 지출을 줄여 그수익을 소비자에게 환원시켜주는 선진형 판매방식입니다.

네트웍 사업은 회원들의 재구매가 빠른 제품으로 구성되어야 한다는것은 잘아시겠죠?
우리가 하루도 전화를 걸지 않고는 살아갈 수 없다는 것을 님께서도 인정하십니까?
바로 이 전화요금을 현재 기간통신에 후불로 납부하는것을 선불로 카드에 충전해서 쓰는것이 사업입니다.

2000년도 국내 소비시장중 통신시장규모는 자그만치 약24조원이었으며 2001년도는 아직 통계가 나오지 않아 잘모르지만 훨씬 늘어났으며 참고로 말씀드린다면 쌀소비시장은 약 1조원, 자동차시장-약6조, 유류(석유)시장-약6조원이었습니다.
통신시장 규모가 얼마나 큰시장인지 짐작이 가시겠죠?

이 거대통신시장이 이대로 개방된다면우리나라 신경인 통신은 그대로 외국유수업체에 잠식 당할 수 밖에 없습니다.
그래서 정부에서 별정통신을 허용하여 개인전화국(1호사업자)으로 하여금 개방이전에 국제경쟁력을 갖추기 위한 국책사업입니다.

통합선불카드 하나로 시내.외,공중전화 통화는 물론 휴대폰 기종,번호변경없이 011부터 019까지 축기능으로 많은 버튼을 누르지 않고 온가족이 함께 간편하게 사용하실수 있습니다.


물론 상기내용은 아주 기본적인 내용이구요.
자기밑으로 2명만 둘수 있는 바이너리 구조입니다

이외에도 부가산업도 뿐만아니라  수익구조,전자상거래등등 하고싶은 이야기는 많으나 이정도로 설명을 해드리구요 더궁굼하신것들은 직접 상담을 하시거나 회사의 홈페이지를 둘러보시면
되겠읍니다.

 

http://www.dynastytel.co.kr(별정통신)
http://www.clubaqua.co.kr(여행사)
http://www.visiondynasty.com(전자상거래)
http://www.e-dynasty.co.kr(홈페이지)
연락처 : codejang@intizen.com
H.P    : 019-596-9808
수신거부 : e-dynasty@simmani.com 또는 아래의 수신거부 버튼을 눌러주세요

 

 

 

 

원치않으시면 수신거부 를 눌러주시고 제목에 수신거부라고 적어주시기 바랍니다. 불편을 드렸다면 죄송합니다. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 14 11:57:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27552 for ; Thu, 14 Feb 2002 11:57:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10837 for enum-archive@odin.ietf.org; Thu, 14 Feb 2002 11:57:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10060; Thu, 14 Feb 2002 11:46:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09971 for ; Thu, 14 Feb 2002 11:46:26 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27059 for ; Thu, 14 Feb 2002 11:46:17 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.224]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g1EGjotQ001786; Thu, 14 Feb 2002 17:45:51 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Feb 2002 17:32:01 +0100 Message-ID: From: "Stastny, Richard" To: "'Lawrence Conroy'" , Jon Cc: enum@ietf.org Subject: RE: [Enum] sipping-e164 comments Date: Thu, 14 Feb 2002 17:31:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi, first I would like to congratulate the authors for this execellent paper on sip AND enum, and here I agree fully with Lawrence, that we need such a paper. And of course, its too much concentrated on telephony and SIP issues, as the title suggests. Here I also agree with Lawrence with his comments to: > * A general sip service should be used, not separate entries > for different > media types ... IMHO opinion it should be the users choice, if he wants to have all services behind SIP or if he wants separate services (providers). Guidance should be given for both cases. I also see SG16 jumping up and down, but that may be resolved easily: First, many statements regarding SIP are also valid for h323, Second, its up to SG16 to write a similar paper, or even better, to upgrade this paper to a generic paper dealing with both (this would be a nice job for TIPHON, hehe, coming up with a draft-ietf-meta-e164-whatever) Taking the volume of the paper, there will be a lot of discussions necessary, on the first reading I have the follwing main issues: 1. Policy: ENUM can only operate on full numbers, no private dialling plans ... I fully understand (and this is also (now) the understanding in SG2 and ETSI), that ENUM according to RFC2916 (currently) only is e164.arpa and full E.164 numbers. In ETSI we start to call this public ENUM. But nobody prevents my company to implement a private ENUM within our Intranet. I can also imagine a client (Outlook?, Messenger?) to recognize a prefix. So if I enter 12345, I query 5.4.3.2.1.telekom.inside, if I enter 0 00441794833666, I query ...e164.arpa and get Lawrence (if he is not in a blue monday loop ;-). Also nobody prevents my company to implement within our network an IN-like ENUM-like service, which is totally separate from the public ENUM (called operator ENUM), eventually running in an extranet with other operators. Although both implementations are not in scope of RFC2916, most of the applications will be the same, so some standardisation or guidance may be needed. 2. Private dialing plans Back to private dialling (and numbering) plans. Many private numbering plans can be reached from the outside (e.g. DDI, especially in Europe). This leads on one hand to the introduction of a Tier 3, where Tier 2 points to the NS of a company, hosting the NAPTR records of the private extensions and are also administrated by the company. Since the company may have her private ENUM (see above), a link to the private ENUM may be nice (eventually hiding some of the internal records?). 3.Incomplete E.164 numbers In addition to the comments from Lawrence, I have a serious problem with section 5.1: "Before a starting string (the telephone number to be reversed) can be constructed in the manner described in RFC2916, the originator of the query SHOULD make sure that the telephone number it intends to resolve is a complete E.164 address. Network elements SHOULD have some means of determining whether an address is complete in the E.164 system, especially when interworking with networks that use overlap PSTN signaling." There is no way currently to make sure that the telephone number is a complete E.164 number, especially on a global scale with a lot of countries having open numbering plans and no fixed number length. Also networks may have no way of determining whether an address is complete. The only way I see is, that the client returns a "incomplete number indication", if no NAPTR records are found in a query of an ENUM domain. The example Lawrence brought up is common with most companies in Germany and Austria. I like the proposal he made with the NAPTR record to the pilot number in Tier 1, but this raises a whole new issue in the administration theater. I would prefer this on Tier 2. 4. "Tel" URLs I always had some problems with the "tel" URLs. In my understanding up to this point I could use "tel" URLs only if I had an operator providing a gateway to the GSTN. To use the tel: to make another lookup to ENUM for that number in ENUM was new for me. (Remark: I fully agree, that ENUM is not a system to change your forwardings every hour). So the "tel" URL is used in this case to point from your secondary number to your primary number, e.g. you have 2 E.164 numbers, but you want to put your NAPTRs only in the primary number, and in the other you have only permanetely the "tel" URL to the primary. When I talked with Patrik last week on this issue, he confirmed, that this can be done (should be done?) also with CNAME Records. If this is the case, than I would propose only to use CNAME for this purpose. I also propose the following for "tel:" If a "tel:" is selected as the outcome of a query by the client on what preference ever, NO additonal ENUM query SHALL be done, the "Tel: Number" SHALL be used to set up a connection to this E.164 number, where ever it is (contact address in SIP terminology). Do not forget, a E.164 number may also terminate on IP (especially with h.323 ;-). Having said this, I will start reading the draft over again ;-) best regards Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com > -----Original Message----- > From: Lawrence Conroy [mailto:lwc@roke.co.uk] > Sent: Wednesday, February 13, 2002 9:15 PM > To: Jon; Rudi > Cc: enum@ietf.org > Subject: [Enum] sipping-e164 comments > > > Hi Folks, > taking Richard at his word that ENUM is an appropriate > place to discuss > the sipping-enum document (and avoiding the wrath of Brian > Rosen by not > cross-posting), I have a few comments; these are not (to my knowledge) > regulatory issues, so most of the group can resume its > horizontal posture. > > First, I must say that I like this work. I'm not quite sure > of the scope, > and have some concerns that it is looking at the scenarios current for > the use in public telecommunications systems only - i.e. it > may have more > to say than the purely technical. However, we need this in > order to give > information that is (correctly) lacking in 2915/2916. My > comments are put > inside square braces. From my reading of the draft:: > > -------------------------- > It has a number of recommendations and disrecommendations. > > My initial scan of these comes up with: > * Use SIP registration services to differentiate > - NAPTR content should show address of record, not current > contact address > - Use a single SIP identity, and let the SIP system > disambiguate between > multiple concurrent contacts (e.g. work and home) > [That's fine *for SIP* but may complicate and/or restrict the > applicability > of ENUM to reference only from IP-based devices. I can at > least envisage > ENUM being used to list my "steam" telephone for use from a > hybrid (or > non-IP based) telephone -- if only as part of a directory > system. Using > a SIP registration service may not be appropriate in all cases.] > > * SIP should be the service of choice. > - Use 'SIP+E2U' rather than a putative 'TEL+E2U' service field > - Use 'sip:' rather than 'tel:' scheme within 'SIP+E2U' service > - If records including tel: URIs are present in the NAPTR > resource record > set, then they should be at a lower priority than > 'pure' sip: URI. > [Brave...(this risks SG16 jumping up & down on your > collective heads :). > The arguments for sip: and against tel: are well put. I'll > duck the sip: > versus h232: issue. However... > There may be scenarios in which ENUM is used to identify a > GSTN-connected > device for use when dialing out from another GSTN-connected > device. In > such a scenario, indicating a sip: scheme may automatically > direct the > client to dial out to an MGC/MG combination, only for that > to "bounce > back" to the PSTN again. I may consider my SipPhone to be a > different > service from my "steam" phone, and I'm afraid to admit that the sip > service pointing at the AoR known to the registrar with > which my SipPhone > is associated may not be listed as the highest order. Maybe > in a year... > Disambiguation using a single SIP AoR is a good idea IFF > there is *a* SIP > service provider with which I have (a) registration{s}. > However, even if > I do use SIP service, I may have more than one provider - I > have more than > one email account, and (even for SIP systems) the text in > the draft reflects > only one view of the future.] > > * Although NAPTRs use regexp, the examples in 2916 all > use the "throw > it away and replace with" form. This SHOULD be used. > [Absolutely agree. One could argue that alternatives SHOULD > NEVER be used, > if only as they represent a nightmare for validation prior > to populating > the domain space, and can easily lead to unintended > mappings. Fuzzy matching > is useful for URN resolution, but fuzzy replacement is > totally inappropriate > for many other uses; not only the e164.arpa hierarchy.] > > * The contents of any tel: URI must not refer to the zone > in which it > is placed (i.e. there should not be a 'tight loop', > with a phone number > mapping to itself). > [This is well put. There should be some specification for > expected Client > treatment of looping behaviour in ENUM queries, or in > recursive recursive > recursive ENUM queries on telephone numbers. However... > I may want to indicate that this is a "final" telephone > number, and that > even though other records exist within the e164.arpa > hierarchy for which > I am authoritative, I do not wish this particular traversal > to continue. > An easy way of doing this is to force a tight loop. The > expected client > behaviour in this circumstance might be to use the current > zone as the > number to dial out. It's inelegant (and occupies space in > the database) > so perhaps enabling an "outer" recursion stopper in the > ENUM system using > a cleaner (and more compact) format is a candidate for the > proposed update > to RFC2916. Note that this deals with re-submission of tel: > URIs to the ENUM > hierarchy, and so does not affect RFC2915. > A client MUST be ready to handle loops, not only this tight loop. > For example, I might have two zones; one associated with my > cell phone with > the other associated with my work phone. > Given the genius of our architects, the building in which I > work has no cell > phone coverage. Thus I have been known to forward calls to > my cell phone to > my work number. Also given that some people are unaware of > the concept of > time zones, I have been known to forward my work calls to > my cell phone. > Yes, I have forgotten and left a loop in place, notably on > Monday morning. > This is bound to happen within the ENUM system, so I'd > suggest that there > should be some text proposing expected behaviour in the > face of such a loop. > Whilst servers should be ready to handle such looping > behaviour on the part > of clients, it SHOULD be at least SHOULD strength on > clients, and ideally > such expanded text is a candidate for the RFC2916 update > Patrik proposed.] > > * A general sip service should be used, not separate entries > for different > media types. Thus, a basic sip URI is MUCH preferred to > separate entries > specifying different media types (e.g. an entry for > SIP+E2VOICE, with > another for SIP+E2VIDEO). This argument extends to a > disrecommendation > of IM+E2U and PRES+E2U (or SIP+E2IM and SIP+E2PRES). > [I am not happy completely with this proposal. Whilst I fully > agree that > partitioning entries for real-time media service with > separate NAPTR records > is not a good idea, there may well be a separation between > real-time media > service (using SIP), and non-real time service such as > presence or IM > -- I for one may not use the same service provider for my > multimedia service > and my "non-real-time" IM or presence service.] > > * DNS returns common (or public) information, and SIP can be > used to avoid > some of the privacy issues by requiring authentication. > However, it may > be a bad idea to put identifiable information into a SIP+E2U > NAPTR record > so may have unintended > consequences. The > DNS system will return this information to anyone > sending the query and > exhaustive search of the e.164.arpa space could easily > extract it. > [Very good point - if only as the ENUM server operators will > be unamused at > groups of people doing exhaustive queries of the domain space.] > > -------------------------- > > The draft also includes some limitations of ENUM, as > described in RFC2916. > This list is interesting, and seems to reflect the intended > use of 2915 and > 2916 for public telecommunications based resources. Thus: > > * Arbitrary strings are not used. > [this is certainly true for the e164.arpa domain space.] > > * Private number spaces cannot be used. > [Strictly, this is because ENUM as currently envisaged, > operates using E.164 > number space. I can use a full ENUM system that is > unconnected with the > rest of the world for my enterprise; I may not interconnect > any private > ENUM-like directory service with the public one and expect > it to work. > Does anyone use unregistered IP addresses within internal > (unconnected) > IP networks? Yes, it is a pain when migrating, but it happens.] > > * National (or origin-dependent) numbers cannot be used without > conversion > to E.164 number form. > [ENUM operates using E.164 number space; I'm not sure that unqualified > national (or local) numbers are within this space.] > > * Incomplete E.164 numbers cannot be indicated as such by ENUM > [Actually, this is may be a parochial view; ENUM deals with a > number space > that "descends" from a global E.164 root. > In some regions, there are variable length numbers, even > within a given > number block. It is perfectly possible to phone +498938450, > or to phone > +498938452525 -- one reaches the "pilot number" for the > Munich Park Hilton > whilst the other reaches the reservation desk. > Although each of these, *in the current public telephone > network* will be a > leaf zone, this need not be the case for all future systems. > Thus, a particular zone within a hierarchy akin to ENUM Tier1 > might, in the > future, include a NAPTR record referring to a "pilot > number", as well as a > set of sub-zones referring to extensions within an > enterprise; a query may > not be incomplete but target the parent zone within which > an enterprise's > DDI sub-zones are stored - this could result in a "pilot > number" being > returned. Whilst this would not be used in the current > infrastructure, it > is perfectly valid within the DNS (e.g. cnn.com returns a > valid A record), > and I'm not happy that we exclude this for all time - It's > a GSTN limitation. > > As an aside, it's a goal to specify the operation of the > currently envisaged > public telecommunications ENUM system - that's one of the > charter items for > the IETF ENUM WG, I believe. Perhaps this text reflects > that goal, in which > case I wonder if it should be extracted and placed in another draft? > > Conversely, a particular number block within the ENUM > hierarchy may have no > NAPTR records but instead consist solely of NS records > pointing to Tier2 > leaf zone servers. The absence of such a NAPTR record > should be indication > to a client that either the authoritative server has no > appropriate entry > or that the query zone is a parant only (e.g. they have > entered an incomplete > number).] > > * The reason for E.164 prefix entries and expected > behaviour on receipt > of a query for them is not specified. > [Strictly, it is perfectly valid to query within the > e164.arpa domain space > for a "non-leaf" zone. One can send a query for the NS > resource record > associated with a non-leaf zone (rather than the NAPTR), > for example. > Equally, one may query the SOA resource record for a parent zone. > As suggested above, it may even be valid to have a NAPTR > associated with a > parent zone. Thus the comment that it is not meaningful to > create records > at non-leaf zones, or to send a query on such a zone (with > an "incomplete" > number) is too strong. They may be the exception within the > normal operation > of ENUM, but there may be valid reasons for entering the records and > performing some queries on non-leaf zones.] > > -------------------------- > > best regards, > Lawrence > -- > lwc@roke.co.uk: +44 1794 833666::: > > _______________________________________________ > 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 daemon@optimus.ietf.org Thu Feb 14 13:48:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05856 for ; Thu, 14 Feb 2002 13:48:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17587 for enum-archive@odin.ietf.org; Thu, 14 Feb 2002 13:48:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17168; Thu, 14 Feb 2002 13:39:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17138 for ; Thu, 14 Feb 2002 13:39:02 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05663 for ; Thu, 14 Feb 2002 13:38:59 -0500 (EST) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062516; Thu, 14 Feb 2002 18:39:00 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Thu, 14 Feb 2002 18:38:58 +0000 To: paf@cisco.com, Rudi From: Lawrence Conroy Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: Update of RFC 2916 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi folks, further on Patrik's request for ideas for update to 2916: * Please can we have some added text on expected client behaviour when loops are detected? This would be at or around line 241. * The example at line 234 includes a tight loop; is this intended? I'm not completely sure this is an easy change. There is no obvious mechanism to indicate that a "tel:" URL contents is "final" i.e. DO NOT re-submit the request to ENUM (as suggested at line 239-240). One (ugly) way of doing this is exactly as in the current example - force a tight loop. Whether or not there is a more elegant way of doing this with NAPTR/DDDS is an open question. * The examples throughout 2916 use the "throw away and start again" (!^.*$!) form for regexp. Should this form be recommended explicitly in the document (please :)? * I believe that tel: URI contents MUST include (according to RFC2806) a global_phone_number. (In RFC2806 this is a SHOULD, but for e.164.arpa, it really is a MUST, IMHO). Please can we have some text stating this in the document? best regards, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 14 23:20:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18255 for ; Thu, 14 Feb 2002 23:20:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA14348 for enum-archive@odin.ietf.org; Thu, 14 Feb 2002 23:20:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13885; Thu, 14 Feb 2002 23:10:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13848 for ; Thu, 14 Feb 2002 23:10:42 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18144 for ; Thu, 14 Feb 2002 23:10:38 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1F49mb08767; Thu, 14 Feb 2002 23:09:49 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4AWS>; Thu, 14 Feb 2002 22:09:43 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF3B@VA02> From: "Peterson, Jon" To: "'Lawrence Conroy'" , "Peterson, Jon" , Rudi Cc: enum@ietf.org Date: Thu, 14 Feb 2002 22:09:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: sipping-e164 comments Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I'm glad you enjoyed the draft, Lawrence. A couple of comments below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Lawrence Conroy [mailto:lwc@roke.co.uk] > Sent: Wednesday, February 13, 2002 12:15 PM > To: Jon; Rudi > Cc: enum@ietf.org > Subject: sipping-e164 comments > [snip] > > - Use a single SIP identity, and let the SIP system disambiguate between > multiple concurrent contacts (e.g. work and home) > [That's fine *for SIP* but may complicate and/or restrict the applicability > of ENUM to reference only from IP-based devices. I can at least envisage > ENUM being used to list my "steam" telephone for use from a hybrid (or > non-IP based) telephone -- if only as part of a directory system. Using > a SIP registration service may not be appropriate in all cases.] Well, this is pretty obviously a SIP-specific draft - not all of this will serve as general recommendations for ENUM. To be clear, though, ENUM is a system that turns E.164 numbers into URIs - if it were designed to point to individual devices then the feature-richness of a URI wouldn't be required (we could define an 'E24' resolution service for IPv4 addresses). Also, as I'm sure you know the draft recommends the one-record model for SIP-based records alone. For example, I've read that this sort of one-record model isn't appropriate for VPIM. [snip] > There may be scenarios in which ENUM is used to identify a GSTN-connected > device for use when dialing out from another GSTN-connected device. In > such a scenario, indicating a sip: scheme may automatically direct the > client to dial out to an MGC/MG combination, only for that to "bounce > back" to the PSTN again. I may consider my SipPhone to be a different > service from my "steam" phone, and I'm afraid to admit that the sip > service pointing at the AoR known to the registrar with which my SipPhone > is associated may not be listed as the highest order. Maybe in a year... We do include a proviso for a tel URL so that ENUM can call out to the GSTN if necessary. I agree with what I think to be your core proposition here - that even an SS7 switch could be equipped with an ENUM interface, and it could use it for its own number routing functions. > Disambiguation using a single SIP AoR is a good idea IFF there is *a* SIP > service provider with which I have (a) registration{s}. However, even if > I do use SIP service, I may have more than one provider - I have more than > one email account, and (even for SIP systems) the text in the draft reflects > only one view of the future. This is really a tough question - I expect this to be the most controversial SIP issue in the draft. I really believe that the problem of possessing multiple AoRs is a pseudo-problem. The issue here is really the way that ENUM would decide which one of many SIP addresses-of-record to use. As an author of ENUM records, you would probably have to decide 'this is my priority one AoR, and this is my priority two AoR'. Presumably what will happen when prospective users get this information is that they will try to call you at the first AoR, and if there are no devices registered there, or the call fails for whatever reason, they'll try to call at you at the second AoR. This information is static - as an author of a record set, you aren't going to update your ENUM records every time you go from work to home, so your first AoR will always be attempted first, and your second second. I suppose if you really didn't care about preference you could also just give them equal preference and let chance decide on a per-call basis. Ultimately, this strikes me as a little forced, and contrary to the SIP model. A SIP AoR isn't a device - it's an identity under which devices register. Registration allows dynamism that is responsive to the needs that motivate having multiple AoRs - that you communicate in different contexts, and that you are available from different places at different times. A user has a prerogative to register devices (and other AoRs) under the AoR of their choosing. Even if there are specific devices that you cannot move out from under a particular AoR (thanks to walled-garden service deployments) as your context changes, clearly the above flow would resolve much more smooth if you registered the AoR that isn't under your control under another AoR which is, and composed your communications there. AoRs, I think, will never be a scarce commodity - they are just identities, like email addresses today. I foresee no technical, political or economic issues that might discourage this view in the future - this is a great deal of the core value of SIP. For these reasons, we do strongly that you have one AoR in ENUM, and let SIP do the rest. If you still disagree after reading the above (and re-reading section 3.5 of the doc), then by all means follow your own counsel - we won't hold it against you. Our primary goal in the draft is bring these issues to your attention. > > * A general sip service should be used, not separate entries for different > media types. Thus, a basic sip URI is MUCH preferred to separate entries > specifying different media types (e.g. an entry for SIP+E2VOICE, with > another for SIP+E2VIDEO). This argument extends to a disrecommendation > of IM+E2U and PRES+E2U (or SIP+E2IM and SIP+E2PRES). > [I am not happy completely with this proposal. Whilst I fully agree that > partitioning entries for real-time media service with separate NAPTR records > is not a good idea, there may well be a separation between real-time media > service (using SIP), and non-real time service such as presence or IM > -- I for one may not use the same service provider for my multimedia service > and my "non-real-time" IM or presence service.] I believe IM and presence are very much real-time services. As an aside, note that we do say that non-real-time services (like HTTP and SMTP) could probably best be managed by ENUM rather than SIP. And incidentally, even if you do use different service providers for voice and IM, pursuant to my point in the previous section, I still believe the two could be composed under a single AoR if necessary. That said, I am secretly somewhat sympathetic to 'PRES+E2U', because you would probably send a SUBSCRIBE to the URI it identifies rather than an INVITE. Admittedly, if there were only a 'SIP+E2U' URI, you'd still just send a SUBSCRIBE to that if you wanted presence. But this is a story for another day. > [snip] > Thus, a particular zone within a hierarchy akin to ENUM Tier1 might, in the > future, include a NAPTR record referring to a "pilot number", as well as a > set of sub-zones referring to extensions within an enterprise; a query may > not be incomplete but target the parent zone within which an enterprise's > DDI sub-zones are stored - this could result in a "pilot number" being > returned. Whilst this would not be used in the current infrastructure, it > is perfectly valid within the DNS (e.g. cnn.com returns a valid A record), > and I'm not happy that we exclude this for all time - It's a GSTN limitation. Okay. Personally, I'm not really sure how one handles zones, number ranges, partial E.164 numbers, etc. in ENUM. I've heard a number of pepole talk about potential interpretations for a query that targets a partial number, as well as various roles for records that represent only partial E.164 numbers. I think it might be helpful in 2916bis to provide some guidelines for these sorts of query and records if there are valid reasons for using them. > > As an aside, it's a goal to specify the operation of the currently envisaged > public telecommunications ENUM system - that's one of the charter items for > the IETF ENUM WG, I believe. Perhaps this text reflects that goal, in which > case I wonder if it should be extracted and placed in another draft? I'd be glad if any of the text in the draft can find a happy home. I'll leave that to the discertion of the organizer of any future work on that problem. > > best regards, > Lawrence > -- > lwc@roke.co.uk: +44 1794 833666::: > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 15 04:40:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01038 for ; Fri, 15 Feb 2002 04:40:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09488 for enum-archive@odin.ietf.org; Fri, 15 Feb 2002 04:40:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08952; Fri, 15 Feb 2002 04:31:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08913 for ; Fri, 15 Feb 2002 04:31:18 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00884 for ; Fri, 15 Feb 2002 04:31:16 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1F9TMb31164; Fri, 15 Feb 2002 03:29:23 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4BM6>; Fri, 15 Feb 2002 03:29:17 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF3E@VA02> From: "Peterson, Jon" To: "'Stastny, Richard'" , "'Lawrence Conroy'" , "Peterson, Jon" Cc: enum@ietf.org Subject: RE: [Enum] sipping-e164 comments Date: Fri, 15 Feb 2002 03:29:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Thanks for your notes, Richard. A few comments below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Stastny, Richard [mailto:richard.stastny@oefeg.at] > Sent: Thursday, February 14, 2002 8:32 AM > To: 'Lawrence Conroy'; Jon > Cc: enum@ietf.org > Subject: RE: [Enum] sipping-e164 comments > > > Hi, > > first I would like to congratulate the authors for this execellent paper on > sip AND enum, and here I agree fully with Lawrence, that we need such a > paper. > > And of course, its too much concentrated on telephony and SIP issues, as the > title suggests. I hope we cannot be faulted for that; as a choice of scope it intended no offense to alternatives. Also note that it is a WG item of the SIPPING WG, not ENUM, though we believe its scope requires review in both working groups. [snip] > > I also see SG16 jumping up and down, but that may be resolved easily: > First, many statements regarding SIP are also valid for h323, > Second, its up to SG16 to write a similar paper, or even better, to upgrade > this paper to a generic paper dealing with both (this would be a nice job > for TIPHON, hehe, coming up with a draft-ietf-meta-e164-whatever) Actually, I feel that H.323 and SIP are different in a number of well-known respects, not the least of which is that I understand the commonly-deployed versions of H.323 do not use URIs. I think we probably do need a SIP-specific draft given some of the differences between the two. Certainly, we invite any experts in H.323 to undertake a similar endeavor - I'd be happy to provide any support I could to that purpose. I don't think my own expertise anyway would be sufficient to take that on. > [snip] > > Also nobody prevents my company to implement within our network an IN-like > ENUM-like service, which is totally separate from the public ENUM (called > operator ENUM), eventually running in an extranet with other operators. To the extent that our document speaks to this issue, we understand that what is called "ENUM" is that which is delegated beneath the e164.arpa domain, and that everything else is not called "ENUM". I think this follows RFC2916 as it is written today (maybe it will change in bis). I am aware of the sorts of discussions you are referring to above (about "public ENUM" and so forth), but we're just trying to stick to exactly what we read in the IETF standard. As you surmise there is no technological impedement to reusing the underlying technology (NAPTR) for non-E.164 numbers - it is just a choice of scope as well. But note that this choice of scope entails unique policy benefits that we find desirable. > [snip] > There is no way currently to make sure that the telephone number is a > complete E.164 number, especially on a global scale with a lot of countries > having open numbering plans and no fixed number length. Also networks may > have no way of determining whether an address is complete. I am familiar with this problem; it is the general problem of converting overlap to en bloc signaling in the GSTN. My point is just that ENUM is an en bloc system, not an overlap system; there is nothing comparable to an ISUP ACM (indicating that the address is known to be complete) or a SAM (indicating that more digits have been supplied towards completion) or a SIP 484 (indicating that the address is known to be incomplete). In the absence of these sorts of mechanisms ENUM is left in a bit of a lurch. However, I am aware of GSTN-mechanisms (based on timers) that are used to resolve overlap signaling into en bloc today that make it more tractable to solve this problem before ENUM is invoked. An alternative would be for ENUM to devise a system that differentiated between a failure because a number didn't exist in the system and a failure because an insufficient number of digits were supplied. I'm not aware of any movement in that direction, though. [snip] > > best regards > > Richard STASTNY > OeFEG > Arsenal Objekt 24 > P.O. Box 147 > A-1103 Vienna, Austria > > Tel: +43 664 420 4100 > Fax: +43 1 79780 13 > richard.stastny@oefeg.at > richard@stastny.com > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 15 10:15:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07731 for ; Fri, 15 Feb 2002 10:15:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24908 for enum-archive@odin.ietf.org; Fri, 15 Feb 2002 10:15:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24141; Fri, 15 Feb 2002 10:04:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24096 for ; Fri, 15 Feb 2002 10:04:07 -0500 (EST) Received: from yesky.com ([211.167.73.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07388 for ; Fri, 15 Feb 2002 10:04:05 -0500 (EST) From: john@yesky.com Message-Id: <200202151504.KAA07388@ietf.org> Received: from world([211.144.74.232]) by yesky.com(JetMail 2.5.3.0) with SMTP id jm8f3c6d8bb7; Fri, 15 Feb 2002 14:58:38 -0000 To: enum@ietf.org Content-Type: text/plain; Date: Fri, 15 Feb 2002 23:09:15 +0800 X-Priority: 3 X-Library: Indy 8.0.25 X-Mailer: Send Mail(http://www.co-top.com) Subject: [Enum] =?GB2312?B?yrXP1sT6ILDZIM3yuLsgzsy1xMPOIM/r?= Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org 툉堂： 퀭봤찐？離쐤乖붤봤！첼莖떼澗돕붤뜩붤뜩풀，돨횅먁얾봤섐죄！！ 宅제轟掘돨internet君瞳唐샙삔茄君乖쳬겟 拱말 筐돨촘拳！！ 君瞳乖蕨퀭썽�僕뻗熾팩㎕☎횟阪ː꽂サ켰�풀溝固貢籃“劤 端 적”。 “劤 端 적”：http://rich4all.yeah.net 봤뜩훙繫법侶蘆各썹직契돨“뜩꿔늴貢쭹檀饋 MLM” 냥槨죄겟拱말 筐，侶앎角 Internet 돨제좆！ 꼇狼중鰻똬똬5롸爐珂쇌，섯롸爐鞏鞏삔맣긴훙寧�骸컬璜甲「臼痍촘歌�！꼇狼畓滔： “劤 端 적”：http://rich4all.yeah.net 먀우속흙걸！督豆督봤！묜毆랙꼿！ 퀭돨툉堂：莖뵨 QQ:67262864 ∽ 푤拱깎댄법샙삔！！！∽ _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 15 11:32:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10258 for ; Fri, 15 Feb 2002 11:32:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00239 for enum-archive@odin.ietf.org; Fri, 15 Feb 2002 11:32:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28943; Fri, 15 Feb 2002 11:22:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28916 for ; Fri, 15 Feb 2002 11:22:37 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09947 for ; Fri, 15 Feb 2002 11:22:35 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id IAA19635 for ; Fri, 15 Feb 2002 08:22:06 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id <17L73SF6>; Fri, 15 Feb 2002 08:22:06 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B014B0FB6@opwinex01.corp.illuminet.com> From: Kevin McCandless To: "'enum@ietf.org'" Date: Fri, 15 Feb 2002 08:21:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B63C.E3D14400" Subject: [Enum] Using ENUM for SIP Applications Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@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. ------_=_NextPart_001_01C1B63C.E3D14400 Content-Type: text/plain; charset="iso-8859-1" Comments on "Using ENUM for SIP Applications" 4.4 Provisioning multiple NAPTR records ENUM records are not designed to be updated in real time, and therefore ENUM is not a good mechanism for managing particular devices. Comment: This makes an assumption oh how ENUM will be deployed. There is no reason that ENUM could not be updated by a user in real time and the zone files updated more frequency then the usual 24 hours. There has been discussion of zone file updates as often as every fifteen minutes. Lets leave the provisioning of NAPTR records to the market place to decide how real time the records can be. 5. Processing ENUM records Ideally, the recommendations above for authoring NAPTR records will be followed to the letter; each NAPTR record set will contain a SIP URI (and if possible nothing else). Comment: Once again we are making the assumption for the market place. ENUM is not just for SIP. ENUM can be a DNS directory service. It could easily contain, in the correct format, all of the usual contact information that is listed on a business card. Cheers! Kevin McCandless Senior Network Planner Illuminet (A VeriSign Company) 913-814-6397 kmccandless@illuminet.com ------_=_NextPart_001_01C1B63C.E3D14400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Comments on "Using=20 ENUM for SIP Applications"
4.4 Provisioning multiple NAPTR =
records ENUM records are not designed to be updated in real time, =

and therefore ENUM is not a good =
mechanism for managing particular devices. 
Comment:  This =
makes an assumption oh how ENUM will be deployed.  There is no reason that =
ENUM
could not be updated by a user in real time and the zone files =
updated more frequency then the usual 24 hours.  
There has been discussion =
of zone file updates as often as every fifteen minutes.  Lets leave the provisioning =
of NAPTR 
records to the market place to decide how real time the =
records can be.
5. =
Processing ENUM records 
Ideally, the =
recommendations above for authoring NAPTR records will be followed to =
the letter; each NAPTR
 record set will contain a SIP URI (and if =
possible nothing else).  =
 
Comment:  Once =
again we are making the assumption for the market place.  ENUM is not just for =
SIP.  
ENUM can be a =
DNS directory service.  =
It could easily contain, in the correct format, all of the usual contact information
that =
is listed on a business card.

 Cheers!

Kevin McCandless
Senior Network Planner
Illuminet (A VeriSign=20 Company)
913-814-6397 =
kmccandless@illuminet.com

 
------_=_NextPart_001_01C1B63C.E3D14400-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 15 12:09:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11767 for ; Fri, 15 Feb 2002 12:09:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03786 for enum-archive@odin.ietf.org; Fri, 15 Feb 2002 12:09:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02033; Fri, 15 Feb 2002 11:59:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02004 for ; Fri, 15 Feb 2002 11:59:16 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11247 for ; Fri, 15 Feb 2002 11:59:13 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA00426; Fri, 15 Feb 2002 11:56:56 -0500 (EST) Received: from arutkowski-desk.verisign.com (ARUTKOWSKI-DESK [10.131.128.39]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15YHPXA1; Fri, 15 Feb 2002 11:57:48 -0500 Message-Id: <5.1.0.14.2.20020215113319.025c0618@vsvapostal1.prod.netsol.com> X-Sender: trutkowski@vsvapostal1.prod.netsol.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Feb 2002 11:56:50 -0500 To: "Peterson, Jon" , "'Stastny, Richard'" , "'Lawrence Conroy'" , "Peterson, Jon" From: Tony Rutkowski Subject: RE: [Enum] sipping-e164 comments Cc: enum@ietf.org In-Reply-To: <70565611B164D511957A001083FCDD56CAAF3E@VA02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Jon, >To the extent that our document speaks to this issue, we understand that >what is called "ENUM" is that which is delegated beneath the e164.arpa >domain, and that everything else is not called "ENUM". I think this follows >RFC2916 as it is written today (maybe it will change in bis). I am aware of >the sorts of discussions you are referring to above (about "public ENUM" and >so forth), but we're just trying to stick to exactly what we read in the >IETF standard. As you surmise there is no technological impedement to >reusing the underlying technology (NAPTR) for non-E.164 numbers - it is just >a choice of scope as well. But note that this choice of scope entails unique >policy benefits that we find desirable. It is worth noting, however, that the U.S. Government has explicitly decided this matter differently. For other significant policy benefits, it encourages multiple ENUM and ENUM-like implementations. The relevant document is available at: http://www.ngi.org/enum/geneva200109/46_ww9.doc Another policy "benefit" of the IAB decision: Although impeded by RFC2804, a formally designated ENUM implementation must necessarily comply with Lawful Interception requirements under Council of the European Union Resolution of 17 January 1995, and the U.S. Communications Assistance for Law Enforcement Act of 1994, as amended by the Patriot Act of November 2001. This is within the ambit of technical standards work of the ETSI Standards Development Organization SEC LI Working Group. See TR 101 944, "Telecommunications Security; Lawful Interception (LI); Issues on IP Interception." --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 15 12:37:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13087 for ; Fri, 15 Feb 2002 12:37:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05838 for enum-archive@odin.ietf.org; Fri, 15 Feb 2002 12:37:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04858; Fri, 15 Feb 2002 12:27:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04827 for ; Fri, 15 Feb 2002 12:27:51 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12535 for ; Fri, 15 Feb 2002 12:27:48 -0500 (EST) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA15876; Fri, 15 Feb 2002 09:27:49 -0800 Message-Id: <5.1.0.14.2.20020215092215.02695008@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Feb 2002 09:27:44 -0800 To: Tony Rutkowski From: Dave Crocker Subject: RE: [Enum] sipping-e164 comments Cc: enum@ietf.org In-Reply-To: <5.1.0.14.2.20020215113319.025c0618@vsvapostal1.prod.netsol .com> References: <70565611B164D511957A001083FCDD56CAAF3E@VA02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Tony, At 11:56 AM 2/15/2002 -0500, Tony Rutkowski wrote: >>To the extent that our document speaks to this issue, we understand that >>what is called "ENUM" is that which is delegated beneath the e164.arpa > >It is worth noting, however, that the U.S. Government has >explicitly decided this matter differently. 1. It is worth noting that you keep raising political issues in a technical forum. The IETF does not work on the basis of governments. It works on the basis of engineering. 2. It is worth noting that your characterization of the submission to the ITU is just plain wrong. Yes, it uses the word ENUM more generally than e164.arpa, but a) it notes the need for a single, coordinated operation, and b) use of the term ENUM was not offered as a decision. 3. By the way, the term ENUM is defined by the IETF in its document. How others choose to use that term is their business, not the IETF's. Given the pattern of your postings to this mailing list, it remains a mystery what purpose you are trying to serve. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 15 14:35:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17232 for ; Fri, 15 Feb 2002 14:35:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12919 for enum-archive@odin.ietf.org; Fri, 15 Feb 2002 14:35:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11787; Fri, 15 Feb 2002 14:21:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11758 for ; Fri, 15 Feb 2002 14:21:32 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16475 for ; Fri, 15 Feb 2002 14:21:29 -0500 (EST) Received: from dick.neustar.biz (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1FJL0b31112 for ; Fri, 15 Feb 2002 14:21:00 -0500 Message-Id: <5.1.0.14.2.20020215141728.044cde90@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Feb 2002 14:18:05 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: Internet-Draft Cutoff Dates for Minneapolis, MN Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Reminder: >To: IETF-Announce: ; >From: Internet-Drafts Administrator >Subject: Internet-Draft Cutoff Dates for Minneapolis, MN >Date: Fri, 15 Feb 2002 07:03:31 -0500 >Sender: nsyracus@cnri.reston.va.us > > >NOTE: There are two (2) Internet-Draft Cutoff dates > >February 22nd: Cutoff for Initial Submissions (new documents) > >All initial submissions(-00) must be submitted by Friday, >February 22nd, 17:00 US-EST. Initial submissions received after this time >will NOT be made available in the Internet-Drafts directory, and will have >to be resubmitted. > >As before, all initial submissions (-00.txt) with a filename beginning >with a draft-ietf MUST be approved by the appropriate WG Chair prior to >processing and announcing. WG Chair approval must be received by >Monday, February 25th. > >Please do NOT wait until the last minute to submit. > >Be advised: NO placeholders. Updates to initial submissions received > the week of February 22nd will NOT be accepted. > >March 1st: FINAL Internet-Draft Cutoff > >All revised Internet-Draft submissions must be submitted by Friday, >March 1st, 2002 at 17:00 US-EST. Internet-Drafts received after this time >will NOT be announced NOR made available in the Internet-Drafts >Directories. > >We will begin accepting Internet-Draft submissions the week of the >meeting, though announcements will NOT be sent until the IETF meeting >is over. > >Thank you for your understanding and cooperation. Please do not hesitate >to contact us if you have any questions or concenrs. > >FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_53.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 15 14:45:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17634 for ; Fri, 15 Feb 2002 14:45:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13370 for enum-archive@odin.ietf.org; Fri, 15 Feb 2002 14:45:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12819; Fri, 15 Feb 2002 14:33:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12789 for ; Fri, 15 Feb 2002 14:33:41 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17155 for ; Fri, 15 Feb 2002 14:33:38 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id LAA04027 for ; Fri, 15 Feb 2002 11:33:09 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id <17L734P0>; Fri, 15 Feb 2002 11:33:09 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B014B0FC0@opwinex01.corp.illuminet.com> From: Kevin McCandless To: "'enum@ietf.org'" Date: Fri, 15 Feb 2002 11:33:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B657.96A2DBB0" Subject: [Enum] SIpping-e164 comments Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@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. ------_=_NextPart_001_01C1B657.96A2DBB0 Content-Type: text/plain; charset="iso-8859-1" Here are some comments on sipping-e164.......... 4.4 Provisioning multiple NAPTR records ENUM records are not designed to be updated in real time, and therefore ENUM is not a good mechanism for managing particular devices. Comment: This makes an assumption oh how ENUM will be deployed. There is no reason that ENUM could not be updated by a user in real time and the zone files updated more frequency then the usual 24 hours. There has been discussion of zone file updates as often as every fifteen minutes. Lets leave the provisioning of NAPTR records to the market place to decide how real time the records can be. 5. Processing ENUM records Ideally, the recommendations above for authoring NAPTR records will be followed to the letter; each NAPTR record set will contain a SIP URI (and if possible nothing else). Comment: Once again we are making the assumption for the market place. ENUM is not just for SIP. ENUM can be a DNS directory service. It could easily contain, in the correct format, all of the usual contact information that is listed on a business card. Cheers! Kevin ------_=_NextPart_001_01C1B657.96A2DBB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Here are some comments on=20 sipping-e164..........
4.4 Provisioning multiple NAPTR =
records ENUM records are not designed to be updated in real time, =

and therefore ENUM is not a good =
mechanism for managing particular devices. 
Comment:  This makes an assumption oh how ENUM will be =
deployed.  There is no =
reason that ENUM
could not be updated by a user in real time and the =
zone files updated more frequency then the usual 24 hours.  
There has been discussion =
of zone file updates as often as every fifteen minutes.  Lets leave the provisioning =
of NAPTR 
records to the market place to decide how real time the =
records can be.
5. =
Processing ENUM records 
Ideally, the =
recommendations above for authoring NAPTR records will be followed to =
the letter; each NAPTR
 record set will contain a SIP URI (and if =
possible nothing else).  =
 
Comment:  Once =
again we are making the assumption for the market place.  ENUM is not just for =
SIP.  
ENUM can be a =
DNS directory service.  =
It could easily contain, in the correct format, all of the usual contact information
that =
is listed on a business card.

 Cheers!

Kevin

------_=_NextPart_001_01C1B657.96A2DBB0-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 15 17:17:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21507 for ; Fri, 15 Feb 2002 17:17:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22008 for enum-archive@odin.ietf.org; Fri, 15 Feb 2002 17:17:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21610; Fri, 15 Feb 2002 17:08:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21579 for ; Fri, 15 Feb 2002 17:08:32 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21227 for ; Fri, 15 Feb 2002 17:08:30 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1FM7ub28612; Fri, 15 Feb 2002 16:07:56 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4239>; Fri, 15 Feb 2002 16:07:51 -0600 Message-ID: <23309E398D84D5119D0F00306E0751390124E9C1@dc02.npac.com> From: "McGarry, Tom" To: "'Tony Rutkowski'" , "Peterson, Jon" Cc: enum@ietf.org Subject: RE: [Enum] sipping-e164 comments Date: Fri, 15 Feb 2002 16:07:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org The point that Jon is making pertains to the scope of the document. The RFC designates e164.arpa as the enum domain. Jon's draft, being consistent with the RFC, is limited in scope to delegations within e164.arpa. BTW, I felt the need to point out the following statement in the US Government's position regarding PARTICIPATION IN A GLOBAL COMMON ENUM DNS DOMAIN: "With respect to the choice of a possible, coordinated, global ENUM DNS domain, the United States supports the conclusion in IETF RFC 2916, which designates E164.arpa for this purpose." Thanks, Tom -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@verisign.com] Sent: Friday, February 15, 2002 11:57 AM To: Peterson, Jon; 'Stastny, Richard'; 'Lawrence Conroy'; Peterson, Jon Cc: enum@ietf.org Subject: RE: [Enum] sipping-e164 comments Hi Jon, >To the extent that our document speaks to this issue, we understand that >what is called "ENUM" is that which is delegated beneath the e164.arpa >domain, and that everything else is not called "ENUM". I think this follows >RFC2916 as it is written today (maybe it will change in bis). I am aware of >the sorts of discussions you are referring to above (about "public ENUM" and >so forth), but we're just trying to stick to exactly what we read in the >IETF standard. As you surmise there is no technological impedement to >reusing the underlying technology (NAPTR) for non-E.164 numbers - it is just >a choice of scope as well. But note that this choice of scope entails unique >policy benefits that we find desirable. It is worth noting, however, that the U.S. Government has explicitly decided this matter differently. For other significant policy benefits, it encourages multiple ENUM and ENUM-like implementations. The relevant document is available at: http://www.ngi.org/enum/geneva200109/46_ww9.doc Another policy "benefit" of the IAB decision: Although impeded by RFC2804, a formally designated ENUM implementation must necessarily comply with Lawful Interception requirements under Council of the European Union Resolution of 17 January 1995, and the U.S. Communications Assistance for Law Enforcement Act of 1994, as amended by the Patriot Act of November 2001. This is within the ambit of technical standards work of the ETSI Standards Development Organization SEC LI Working Group. See TR 101 944, "Telecommunications Security; Lawful Interception (LI); Issues on IP Interception." --tony _______________________________________________ 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 daemon@optimus.ietf.org Fri Feb 15 17:27:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21760 for ; Fri, 15 Feb 2002 17:27:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22566 for enum-archive@odin.ietf.org; Fri, 15 Feb 2002 17:27:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22060; Fri, 15 Feb 2002 17:18:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22033 for ; Fri, 15 Feb 2002 17:18:56 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21552 for ; Fri, 15 Feb 2002 17:18:54 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id RAA16194; Fri, 15 Feb 2002 17:18:16 -0500 (EST) Received: from arutkowski-desk.verisign.com (ARUTKOWSKI-DESK [10.131.128.39]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15YHP0TT; Fri, 15 Feb 2002 17:19:08 -0500 Message-Id: <5.1.0.14.2.20020215171235.025f8a48@vsvapostal1.prod.netsol.com> X-Sender: trutkowski@vsvapostal1.prod.netsol.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Feb 2002 17:18:12 -0500 To: "McGarry, Tom" , "Peterson, Jon" From: Tony Rutkowski Subject: RE: [Enum] sipping-e164 comments Cc: enum@ietf.org In-Reply-To: <23309E398D84D5119D0F00306E0751390124E9C1@dc02.npac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 05:07 PM 2/15/2002, McGarry, Tom wrote: >"With respect to the choice of a possible, coordinated, global ENUM DNS >domain, the United States supports the conclusion in IETF RFC 2916, which >designates E164.arpa for this purpose." Hi Tom, The issue revolves around exclusivity. There is nothing wrong with the IAB sponsoring the domain e164.arpa. The issue is whether that's the only possible coordinated global ENUM DNS implementation. For those who may have difficulty using WinWord, the full ASCII text reads: ENUM, as a protocol recommended by the Internet Engineering Task Force (IETF) in RFC 2916, is still in a nascent stage as a potential service to end-users. Although significant work remains to be done in order to understand better the domestic public policy implications of ENUM deployment in the United States, the United States believes that pursuing a coordinated, global DNS domain for ENUM may provide opportunity for both industry and consumers and, therefore, may have merit. At the same time, the implementation of such a system must neither preclude deployments of ENUM and other similar protocols in any other top level DNS domain, nor restrict the development of other innovative services that may serve as competing ENUM alternatives. In any deployment of ENUM, the United States believes that a number of principles must be observed. First, the sovereignty of Member States to determine whether and in what manner to implement ENUM in a coordinated, global DNS domain with respect to an individual Member State's Recommendation E.164 resources must be clearly affirmed and as such, Member States retain the right to choose whether to "opt in" to such a coordinated, global ENUM DNS domain. Second, any possible participation by the United States in a coordinated, global ENUM DNS domain must allow for competition in as many administrative and operational functions as feasible. In addition, we note that the promotion of interworking between different approaches and systems should be an ongoing pursuit. Finally, a coordinated, global ENUM DNS domain must not be inconsistent with the positive goals of competition in telecommunications, the encouragement of innovation, the promotion of advanced data services, and the minimization of regulatory involvement and intervention. With respect to the choice of a possible, coordinated, global ENUM DNS domain, the United States supports the conclusion in IETF RFC 2916, which designates E164.arpa for this purpose. The ".arpa" domain is already designated for use by critical infrastructure functions, notably including reverse address mapping; therefore, servers within this top level domain are designed to be technically robust. In addition, we note that the development of a coordinated, global ENUM DNS domain should be viewed as an opportunity to demonstrate the fruitful results of joint, cooperative work between the ITU and the IETF, the creator of the ENUM standard, RFC 2916. In the deployment of a coordinated, global ENUM DNS domain, any ITU role should encourage opportunities for ENUM to evolve as a market-based system with minimal regulatory intervention. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 15 18:09:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22864 for ; Fri, 15 Feb 2002 18:09:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24536 for enum-archive@odin.ietf.org; Fri, 15 Feb 2002 18:09:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23960; Fri, 15 Feb 2002 18:00:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23914 for ; Fri, 15 Feb 2002 18:00:17 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22656 for ; Fri, 15 Feb 2002 18:00:15 -0500 (EST) Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA28626; Fri, 15 Feb 2002 15:00:10 -0800 Message-Id: <5.1.0.14.2.20020215145618.03a7efa0@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Feb 2002 14:59:40 -0800 To: Tony Rutkowski From: Dave Crocker Subject: RE: [Enum] sipping-e164 comments Cc: "McGarry, Tom" , "Peterson, Jon" , enum@ietf.org In-Reply-To: <5.1.0.14.2.20020215171235.025f8a48@vsvapostal1.prod.netsol .com> References: <23309E398D84D5119D0F00306E0751390124E9C1@dc02.npac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 05:18 PM 2/15/2002 -0500, Tony Rutkowski wrote: >The issue revolves around exclusivity. There is >nothing wrong with the IAB sponsoring the domain e164.arpa. Tony, it is a relief to hear that you do not mind having the IAB do its job. >The issue is whether that's the only possible coordinated >global ENUM DNS implementation. Well, no that is not the issue. Yes it is an issue you keep trying to impose on this working group, but it is an issue that has nothing to do with the work of the working group. And, by the way, note that the US text pertains to exploration of additional trees, not requirement for them. Gosh, isn't that remarkable? The US position is to be supportive of exploring additional paths. Wow. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 16 02:23:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08386 for ; Sat, 16 Feb 2002 02:23:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20969 for enum-archive@odin.ietf.org; Sat, 16 Feb 2002 02:23:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20653; Sat, 16 Feb 2002 02:12:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20622 for ; Sat, 16 Feb 2002 02:12:50 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08288 for ; Sat, 16 Feb 2002 02:12:47 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA06422; Sat, 16 Feb 2002 08:12:16 +0100 (MET) Date: Fri, 15 Feb 2002 20:59:22 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org cc: Scott Bradner , Allison Mankin Message-ID: <12778194.1013806762@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Enum] 2916bis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit I have here compiled a list of things to be changed to RFC 2916 when 2916bis is created. (1) It must be made clear that ENUM service is a delegation in the e164.arpa domain (2) It must be explained how ENUM-like mechanisms can be used for for example private dialing plans even though e164.arpa is the tree where ENUM is located (3) The use of NAPTR should instead of being some handwaving be a proper DDDS specification according to the DDDS documents which replaces RFC 2915 (4) A registration mechanism must be created for the first part of the flag field (5) Registrations must be made in separate documents for some basic flags, especially LDAP and TEL which have been asked especially how to handle (6) Privacy issues must be described more clearly in the security consideration section which explains that some privacy issues can be resolved via storage in a secondary storage, like an LDAP database, which uses an access protocol which can handle authentication and other needed security mechanisms (7) Loops must be specified how to detect (i.e. a paragraph should be added which explains the traditional need for convergence) (8) Examples must be corrected and made mode clear. For example, there should be absolutely no confusion about full regular expressions are used. I.e. any delimiter and any matchingh mechanism can be used All of this leads to the need for the following document(s) in this wg: - 2916bis - Registration procedure of ENUM flag fields - Flag field registration for whatever needed for TEL URI scheme - Flag field registration for whatever needed for SIP URI scheme - Flag field registration for whatever needed for MAILTO URI scheme - Flag field registration for whatever needed for LDAP URI scheme I will take care of 2916bis, but as wg co-chair I would appreciate people interested in working on the other documents. I suggest we take these 8 issues (and maybe others) as main agenda items on the IETF meeting in Minneapolis. Further, we add the flag field discussions, if we have takes, to the agenda aswell. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 16 02:31:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08519 for ; Sat, 16 Feb 2002 02:31:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA21710 for enum-archive@odin.ietf.org; Sat, 16 Feb 2002 02:31:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20878; Sat, 16 Feb 2002 02:22:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20851 for ; Sat, 16 Feb 2002 02:22:15 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08363 for ; Sat, 16 Feb 2002 02:22:13 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1G7Lab11038; Sat, 16 Feb 2002 02:21:36 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4KSC>; Sat, 16 Feb 2002 01:21:30 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF4C@VA02> From: "Peterson, Jon" To: "'Kevin McCandless'" , "'enum@ietf.org'" Subject: RE: [Enum] Using ENUM for SIP Applications Date: Sat, 16 Feb 2002 01:21:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Kevin, thanks for your comments. Let me just say to start with that obviously we didn't base our notes on any anticipated operational model from the fora - we just read the standards and tried to figure out the best way to apply them. While I don't doubt that ENUM could be adopted to various requirements it doesn't satisfy today, I'd like to believe that it is a complete and specific tool, because even in its current incarnation I find it quite serviceable. To your first point, although I'm no DNS expert, I think that when I say ENUM isn't designed to be 'real time', there's more to it than just how often records are updated. For example: - The SIP protocol has rules for evaluating a set of registrations and handling requests in a location service - this is comparable to ENUM, it's true. But SIP also has a whole method (REGISTER) for allowing an endpoint, like an IP phone, to authenticate itself to a location service, add/delete/modify contacts for itself or third parties as authorized, and so forth. While there are dynamic protocols I've read about for updating DNS, I don't think these are oriented towards this sort of end-user device registration. - SIP registrations all have an expiration interval after which they will be removed by a location service. Expiration intervals can be brief, so that effectively if a device fails it will automatically and promptly cease to be registered for that identity. The language in the spec says that registration intervals should be allowed to be as short as possible without degrading registrar performance (which in many useful architectures could be very brief indeed). Moreover it suggests a very different model for data than one usually ascribes to DNS - one in which records themselves (as opposed to caches) grow stale if not refreshed and purge themselves. To your second point, we aren't making any sort of normative statement in that sentence - it's a slightly tongue in cheek way of saying that the selection of a NAPTR record is significantly easier if only one record is present. In several places in the document, including the authoring section, we discuss the use of ENUM for HTTP, SMTP, tel URLs, and so on. That much said, though, I think there is a case to be made that ENUM is especially useful for SIP. After all, ENUM is a technology that turns E.164 telephone numbers into URIs; it seems logical that it would have some applicability to a protocol commonly used for Internet telephony that expresses identities with URIs (neither HTTP nor SMTP meet both of those stipulations). Another common use of telephone numbers is SMS - which is met by SIP with SIMPLE. There's even been some SIP for fax work. I suppose VPIM can also claim good applicability, but it would be tough to beat SIP's match. Suffice it to say that I for one believe it will be SIP applications that drive ENUM adoption. Jon Peterson NeuStar, Inc. -----Original Message----- From: Kevin McCandless [mailto:KMcCandless@Illuminet.com] Sent: Friday, February 15, 2002 8:22 AM To: 'enum@ietf.org' Subject: [Enum] Using ENUM for SIP Applications Comments on "Using ENUM for SIP Applications" 4.4 Provisioning multiple NAPTR records ENUM records are not designed to be updated in real time, and therefore ENUM is not a good mechanism for managing particular devices. Comment: This makes an assumption oh how ENUM will be deployed. There is no reason that ENUM could not be updated by a user in real time and the zone files updated more frequency then the usual 24 hours. There has been discussion of zone file updates as often as every fifteen minutes. Lets leave the provisioning of NAPTR records to the market place to decide how real time the records can be. 5. Processing ENUM records Ideally, the recommendations above for authoring NAPTR records will be followed to the letter; each NAPTR record set will contain a SIP URI (and if possible nothing else). Comment: Once again we are making the assumption for the market place. ENUM is not just for SIP. ENUM can be a DNS directory service. It could easily contain, in the correct format, all of the usual contact informationthat is listed on a business card. Cheers! Kevin McCandless Senior Network Planner Illuminet (A VeriSign Company) 913-814-6397 kmccandless@illuminet.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 16 03:31:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09102 for ; Sat, 16 Feb 2002 03:31:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA23991 for enum-archive@odin.ietf.org; Sat, 16 Feb 2002 03:31:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23283; Sat, 16 Feb 2002 03:20:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23253 for ; Sat, 16 Feb 2002 03:20:57 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08943 for ; Sat, 16 Feb 2002 03:20:53 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA10656; Sat, 16 Feb 2002 09:19:59 +0100 (MET) Date: Sat, 16 Feb 2002 09:13:54 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Kevin McCandless , "'enum@ietf.org'" Subject: Re: [Enum] SIpping-e164 comments Message-ID: <13091334.1013850834@localhost> In-Reply-To: <1C1EEC765F843E44996971A80682118B014B0FC0@opwinex01.corp.illuminet.com> References: <1C1EEC765F843E44996971A80682118B014B0FC0@opwinex01.corp.illumin et.com> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-15 11.33 -0800 Kevin McCandless wrote: > 4.4 Provisioning multiple NAPTR records ENUM records are not designed to > be updated in real time, > and therefore ENUM is not a good mechanism for managing particular > devices. The idea behind this was really about "real time" updates because of the caching mechanism in DNS. I didn't want to bring in a tutorial of DNS in this document ;-) > Comment: This makes an assumption oh how ENUM will be > deployed. There is no reason that ENUM > could not be updated by a user in real time and the zone files updated > more frequency then the usual 24 hours. It all depends on what you mean by Real Time. My definition is that if a user at time N updates his records, at time N+1 (seconds) a client somewhere should be guaranteed to have the new data. That can never happen with DNS. Nothing in DNS says the update should be "usual 24 hours". I have never heard anything like that. Where have you got that information from? (I am just curious.) > There has been discussion of zone file updates as often as every fifteen > minutes. Lets leave the provisioning of NAPTR > records to the market place to decide how real time the records can be. It is important to in some way mention that instant update (or some other word) will _not_ be possible because of how DNS works. Exactly how often is up to the DNS, and maybe new inventions in DNS. If you use dns-notify then the authoritative servers are up to date. If you use short TTL, then the records themselves will be updated often. But, the time can not be zero. I appreciate suggestions on new wording. > 5. Processing ENUM records > Ideally, the recommendations above for authoring NAPTR records will be > followed to the letter; each NAPTR > record set will contain a SIP URI (and if possible nothing else). > Comment: Once again we are making the assumption for the market place. > ENUM is not just for SIP. > ENUM can be a DNS directory service. It could easily contain, in the > correct format, all of the usual contact information > that is listed on a business card. I agree completely. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 16 10:31:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13149 for ; Sat, 16 Feb 2002 10:31:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07221 for enum-archive@odin.ietf.org; Sat, 16 Feb 2002 10:31:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06138; Sat, 16 Feb 2002 10:21:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06095 for ; Sat, 16 Feb 2002 10:21:55 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12892 for ; Sat, 16 Feb 2002 10:21:49 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA06069; Sat, 16 Feb 2002 16:21:03 +0100 (MET) Date: Sat, 16 Feb 2002 16:10:23 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Peterson, Jon" , "'Kevin McCandless'" , "'enum@ietf.org'" Subject: RE: [Enum] Using ENUM for SIP Applications Message-ID: <13806982.1013875823@localhost> In-Reply-To: <70565611B164D511957A001083FCDD56CAAF4C@VA02> References: <70565611B164D511957A001083FCDD56CAAF4C@VA02> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-16 01.21 -0600 "Peterson, Jon" wrote: > That much said, though, I think there is a case to be made that ENUM is > especially useful for SIP. After all, ENUM is a technology that turns > E.164 telephone numbers into URIs Bingo! I think it is important to know that this, and only this, is what ENUM does. Given the requirements to converge towards a service identifier when doing lookups in various systems, it is important that one do each lookup "fast" and go to the next system needed. Or, the time a call setup takes does not have an upper bound. I.e. I try to explain that ENUM is a meta-signalling mechanism which is used _before_ the traditional mechanisms are used. It is not a replacement for anything done today. ENUM do only one thing, turn an E.164 to a set of prioritized URIs. The URIs in turn of course will be a selection of protocol, endpoint identifier and other things a URI can help with. But, still, I don't see any competition between SIP and ENUM. Finding most efficient recommended way of using ENUM and SIP together is one thing. Arguing about "competition" between SIP and ENUM is another. So, as I wrote in my message about what documents I think are needed, registrations of flag fields are needed. And, the registration for SIP has to talk about how to handle this. Should for example the flag in the NAPTR record differ between a SIP URI used for presence and one used for gaming and one used for voice calls? That MUST be resolved, I would say, before the registration document for SIP-related flags is finished. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 16 12:34:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14728 for ; Sat, 16 Feb 2002 12:34:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12084 for enum-archive@odin.ietf.org; Sat, 16 Feb 2002 12:34:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11276; Sat, 16 Feb 2002 12:22:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11251 for ; Sat, 16 Feb 2002 12:22:51 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14402 for ; Sat, 16 Feb 2002 12:22:45 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062551; Sat, 16 Feb 2002 17:22:48 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Sat, 16 Feb 2002 17:22:47 +0000 To: paf@cisco.com From: Lawrence Conroy Cc: enum@ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA11252 Subject: [Enum] Re. 2916bis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 8:59 pm +0100 15/2/02, Patrik F�ltstr�m wrote: >I have here compiled a list of things to be changed to RFC 2916 when >2916bis is created. >(8) Examples must be corrected and made made clear. For example, there >should be absolutely no confusion about (?that?) full regular >expressions are used. >I.e. any delimiter and any matching mechanism can be used To which I reply: I am having major trouble (apart from just reading the DDDS collection :) in finding answers to the following questions: (i) Is there ever a need to have anything other than a "complete replacement" as the rule substitution expression when applying an ENUM query to the e164.arpa domain space? [Point (8) suggests that there is a need for full regular expressions - I can't think of a case where this is needed.] (ii) Is there ever a need to use a non-terminal NAPTR record when dealing with ENUM (e.164.arpa domain space) records? (iii) RFC2916 states that tel: URIs should be re-submitted to the ENUM system, and that the Client is responsible for loop detection. Richard has suggested that this is not needed; a tel: URI should NOT be re-submitted. On reflection, I agree with him - I can't think of a particular reason why such a re-submission is needed either - can anyone else think of a case? [If not, the required tel: flag document is not too hard, and there may not *be* a problem with loops - it also solves Jon's concerns from the sipping-e164 document, I think :] best regards, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 16 16:31:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16882 for ; Sat, 16 Feb 2002 16:31:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19741 for enum-archive@odin.ietf.org; Sat, 16 Feb 2002 16:31:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19074; Sat, 16 Feb 2002 16:22:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19043 for ; Sat, 16 Feb 2002 16:22:33 -0500 (EST) Received: from localhost ([211.228.6.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16719 for ; Sat, 16 Feb 2002 16:22:26 -0500 (EST) Message-Id: <200202162122.QAA16719@ietf.org> Reply-To: dyd2103@kornet.net From: 안성철 To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 17 Feb 2002 06:22:27 +0900 Subject: [Enum] 세상에 이런일이...'광 고' Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org
  

교통사고 보상상담 안내

 
자동차보험 지급기준과 법률상 손해액의 차이 비교[정보]

- 자동차보험 약관에서는 보험금 지급을 약관 지급기준에 의한 산출 금액과 법률상 손해액을 지급할 수 있도록 규정  되어 있습니다.

- 보험사는 위의 두 기준에 의해 보상을 하고 있기에 피해자가 자신의 권리를 아느냐 모르느냐에 따라 천지차이 보상이   이루어지고 있습니다.


그러면 두 기준이 어떤 차이가 있는지 몇 가지만 알아봅니다.

 

보험회사 약관지급기준

법률상 손해액

차이 분석

일

반

부

상

사

고

위자료

①1급상해로6개월입원시  200만

②14급상해                9만

①약500～700만

②약50～100만

 약2～10배 

휴업손해

①소득인정-입증소득액의 80%

        -입증불가 시 일용임금80%

②일용근로자 ;  도시 847,637

                               농촌 900,284

-입증소득전액인정

-통계소득인정가능

 도시일용 900,284

 농촌남자 1,281,150

통계소득인정 시 일용임금의 1.5배～2배

개호비

-인정불가

-사지마비 가정 개호만 인정

-상해정도 따라 인정 인정

-6세미만 입원기간내 인정

 1달에 120만 차이 발생

장

해

발

생

위자료

-장해  20%       80만

-장해 100%     1000만

-장해  20%   1000만

-장해 100%   5000만

  12.5배 차이

      5배 차이

상실수익

(일실이익)

-장해 인정되나 소득상실 없는 경우 50%만 인정

-중간이자공제 L계수적용

-장해 인정되면 100%인정
     (배 차이)

-중간이자공제 H계수

 이자공제 방식에 따라 나이 어릴수록 크게 차이가남

사

망

시

위자료

-20세～60세           3200만

-20세미만 60세 이상    2800만

           5000만

  1.5～1.78배

※ 상기 표는 극히 일부의 차이를 설명한 것임.

교통사고 보상 확실히 알고 받읍시다.
자세한 상담을 원하시면 060-700-2114 로...

            저희 홈으로 오시려면 여기를 클릭  http//www.sos113.com

 교통사고 보상상담 [060-700-2114]

본 메일은 정보통신부 권고 사항에 의거 제목에 [광고]라 표시된 광고 메일입니다.  메일을 읽어 주신데 대해 감사를 드립니다. 더이상 수신을 원치 않으시면 수신거부를 클릭하시어 귀하의 이메일 주소를 끝까지 입력하면 수신거부처리가 됨을 알려 드립니다.
 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 16 19:57:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19007 for ; Sat, 16 Feb 2002 19:57:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA26890 for enum-archive@odin.ietf.org; Sat, 16 Feb 2002 19:57:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26587; Sat, 16 Feb 2002 19:48:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26558 for ; Sat, 16 Feb 2002 19:48:50 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18866 for ; Sat, 16 Feb 2002 19:48:47 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1H0m6b21731; Sat, 16 Feb 2002 18:48:06 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4M1N>; Sat, 16 Feb 2002 18:48:01 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF55@VA02> From: "Peterson, Jon" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "Peterson, Jon" , "'Kevin McCandless'" , "'enum@ietf.org'" Subject: RE: [Enum] Using ENUM for SIP Applications Date: Sat, 16 Feb 2002 18:47:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA26559 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Comments below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Patrik F�ltstr�m [mailto:paf@cisco.com] > Sent: Saturday, February 16, 2002 7:10 AM > To: Peterson, Jon; 'Kevin McCandless'; 'enum@ietf.org' > Subject: RE: [Enum] Using ENUM for SIP Applications > [snip] > > Should for example the flag in the NAPTR record differ between a SIP URI > used for presence and one used for gaming and one used for voice calls? > > That MUST be resolved, I would say, before the registration document for > SIP-related flags is finished. I agree totally. We present quite a few arguments for one perspective on this matter in our document. While we don't go ahead and register any SIP-related flags in the IANA considerations section, future versions of this document are probably as good a place to register 'sip+E2U' as any. I'd be interested to know whether or not there is basically consensus, based on the arguments that we've raised in sipping-e164-01, that we need no ENUM service fields for SIP other than 'sip+E2U'. Maybe if we have time this is something we could discuss in MN, at the discretion of the chairs. > > paf > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 04:23:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03541 for ; Sun, 17 Feb 2002 04:23:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA23952 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 04:23:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23524; Sun, 17 Feb 2002 04:14:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23493 for ; Sun, 17 Feb 2002 04:14:02 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03280 for ; Sun, 17 Feb 2002 04:13:59 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA10405; Sun, 17 Feb 2002 10:13:20 +0100 (MET) Date: Sun, 17 Feb 2002 10:00:35 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy cc: enum@ietf.org Message-ID: <189861.1013940035@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Enum] Re: Re. 2916bis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-16 17.22 +0000 Lawrence Conroy wrote: > To which I reply: > I am having major trouble (apart from just reading the DDDS > collection :) in finding answers to the following questions: > (i) Is there ever a need to have anything other than a "complete > replacement" as the rule substitution expression when applying an ENUM > query to the e164.arpa domain space? Yes, for example if you have LDAP URI's where the original phone number is part of the DN in the search part of the LDAP URI. You can then have the same regular expression for all records (E.164 numbers) that can be reached by LDAP at that server. > (ii) Is there ever a need to use a non-terminal NAPTR record when > dealing with ENUM (e.164.arpa domain space) records? No. That's why RFC 2916 (the current one) only define use of the "U" flag. > (iii) RFC2916 states that tel: URIs should be re-submitted to the ENUM > system, and that the Client is responsible for loop detection. RFC 2916 is unclear. This is why a special document is needed for each value of "XXXX" in "XXXX-E+U". paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 04:25:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03563 for ; Sun, 17 Feb 2002 04:25:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA24003 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 04:25:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23662; Sun, 17 Feb 2002 04:16:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23620 for ; Sun, 17 Feb 2002 04:16:25 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03318 for ; Sun, 17 Feb 2002 04:16:21 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA10411; Sun, 17 Feb 2002 10:13:31 +0100 (MET) Date: Sun, 17 Feb 2002 10:04:00 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Peterson, Jon" , "Peterson, Jon" , "'Kevin McCandless'" , "'enum@ietf.org'" Subject: RE: [Enum] Using ENUM for SIP Applications Message-ID: <202211.1013940240@localhost> In-Reply-To: <70565611B164D511957A001083FCDD56CAAF55@VA02> References: <70565611B164D511957A001083FCDD56CAAF55@VA02> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-16 18.47 -0600 "Peterson, Jon" wrote: > I'd be interested to know whether or not there is basically consensus, > based on the arguments that we've raised in sipping-e164-01, that we need > no ENUM service fields for SIP other than 'sip+E2U'. Maybe if we have > time this is something we could discuss in MN, at the discretion of the > chairs. Yes. MY personal immediate reaction is that it would be good for the client looking up NAPTR records to know what SIP URI is used for each family of services. For example: I (as a person) might have one SIP URI for presence information, one used for gaming, and one for telephony -- simply because I buy/get these services from different service providers, and just like with email, that implies different domain names in the URI. So, a client which is only interested in presence stuff, why open SIP connections to SIP URI's before knowing that SIP URI is not interesting at all? In some cases of course one "SIP" definition is enough, BUT, as soon as you have more than one "kind" of service and more than one SIP URI, I think more information in the flag is needed for faster call setup. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 11:37:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08113 for ; Sun, 17 Feb 2002 11:37:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15392 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 11:37:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14378; Sun, 17 Feb 2002 11:28:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14270 for ; Sun, 17 Feb 2002 11:28:22 -0500 (EST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07945 for ; Sun, 17 Feb 2002 11:28:18 -0500 (EST) Received: from user-2ivelt4.dialup.mindspring.com ([165.247.87.164] helo=dick.ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16cUAV-0004dR-00; Sun, 17 Feb 2002 11:28:03 -0500 Message-Id: <5.1.0.14.2.20020217111137.023832e0@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 17 Feb 2002 11:16:03 -0500 To: Kevin McCandless , "'enum@ietf.org'" From: Richard Shockey Subject: Re: [Enum] SIpping-e164 comments In-Reply-To: <1C1EEC765F843E44996971A80682118B014B0FC0@opwinex01.corp.il luminet.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2988677==_.ALT" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --=====================_2988677==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed > > >5. Processing ENUM records >Ideally, the recommendations above for authoring NAPTR records will be >followed to the letter; each NAPTR > record set will contain a SIP URI (and if possible nothing else). >Comment: Once again we are making the assumption for the market >place. ENUM is not just for SIP. >ENUM can be a DNS directory service. I think the DNS community would prefer it referred to as a database service and not as a directory service ..that is part of the problem the DNS now faces. Directory has all sorts of specific meanings associated with it. > It could easily contain, in the correct format, all of the usual contact > information >that is listed on a business card. Yes but for any number of reasons this is not a very good idea....A pointer to a LDAP that may contain such records might have uses. But that is a application specific issue... > Cheers! > >Kevin >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --=====================_2988677==_.ALT Content-Type: text/html; charset="us-ascii" 


5. Processing ENUM records 
Ideally, the recommendations above for authoring NAPTR records will be
followed to the letter; each NAPTR
 record set will contain a SIP URI (and if possible nothing
else).   

Comment:  Once again we are making the assumption for the
market place.  ENUM is not just for SIP.  
ENUM can be a DNS directory service.

I think the DNS community would prefer it referred to as a database service and not as a directory service ..that is part of the problem the DNS now faces. Directory has all sorts of specific meanings associated with it.

 It could easily contain,
in the correct format, all of the usual contact information
that is listed on a business card.


Yes but for any number of reasons this is not a very good idea....A pointer to a LDAP that may contain such records might have uses.

But that is a application specific issue...


 Cheers!

Kevin


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: rshockey@ix.netcom.com> or
<mailto: rich.shockey@neustar.biz>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--=====================_2988677==_.ALT-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 11:37:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08129 for ; Sun, 17 Feb 2002 11:37:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15406 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 11:37:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14500; Sun, 17 Feb 2002 11:28:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14405 for ; Sun, 17 Feb 2002 11:28:46 -0500 (EST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07950 for ; Sun, 17 Feb 2002 11:28:43 -0500 (EST) Received: from user-2ivelt4.dialup.mindspring.com ([165.247.87.164] helo=dick.ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16cUAO-0004dR-00; Sun, 17 Feb 2002 11:27:56 -0500 Message-Id: <5.1.0.14.2.20020217105405.0235bd50@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 17 Feb 2002 11:07:59 -0500 To: "Stastny, Richard" , "'Lawrence Conroy'" , Jon From: Richard Shockey Subject: RE: [Enum] sipping-e164 comments Cc: enum@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > >And of course, its too much concentrated on telephony and SIP issues, as the >title suggests. >Here I also agree with Lawrence with his comments to: > > * A general sip service should be used, not separate entries > > for different > > media types ... >IMHO opinion it should be the users choice, if he wants to have all services >behind SIP or if he wants separate services (providers). Guidance should be >given for both cases. > >I also see SG16 jumping up and down, but that may be resolved easily: >First, many statements regarding SIP are also valid for h323, >Second, its up to SG16 to write a similar paper, or even better, to upgrade >this paper to a generic paper dealing with both (this would be a nice job >for TIPHON, hehe, coming up with a draft-ietf-meta-e164-whatever) Personally I totally agree ... I think we'd welcome any document that looks at the issues surrounding ENUM and H.323 from SG16, TIPHON or any other source especially in light of SG16's work on the URL http://www.ietf.org/internet-drafts/draft-levin-iptel-h323-url-scheme-04.txt >Taking the volume of the paper, there will be a lot of discussions >necessary, on the first reading I have the follwing main issues: > >1. Policy: >ENUM can only operate on full numbers, no private dialling plans ... >I fully understand (and this is also (now) the understanding in SG2 and >ETSI), that ENUM according to RFC2916 (currently) only is e164.arpa and full >E.164 numbers. In ETSI we start to call this public ENUM. > >Also nobody prevents my company to implement within our network an IN-like >ENUM-like service, which is totally separate from the public ENUM (called >operator ENUM), eventually running in an extranet with other operators. Correct ... >The only way I see is, that the client returns a "incomplete number >indication", if no NAPTR records are found in a query of an ENUM domain. The >example Lawrence brought up is common with most companies in Germany and >Austria. I like the proposal he made with the NAPTR record to the pilot >number in Tier 1, but this raises a whole new issue in the administration >theater. I would prefer this on Tier 2. This is a good point for many reasons. One additonal note that we all should keep in mind is that since 2916 is a global service using DNS all records will be esposed to the global internet ..therefore it is worth noting that only the minimal set of records necessary to set up a call should be exposed in the NAPTR records. >4. "Tel" URLs > >I always had some problems with the "tel" URLs. In my understanding up to >this point I could use "tel" URLs only if I had an operator providing a >gateway to the GSTN. To use the tel: to make another lookup to ENUM for that >number in ENUM was new for me. (Remark: I fully agree, that ENUM is not a >system to change your forwardings every hour). So the "tel" URL is used in >this case to point from your secondary number to your primary number, e.g. >you have 2 E.164 numbers, but you want to put your NAPTRs only in the >primary number, and in the other you have only permanetely the "tel" URL to >the primary. I dont like this either ... using tel URL's for call forwarding exposed personal preferences to the global internet ant those functions should be executed by either the SIP proxy. Using Tel URL's for gateway location is also a bad idea since there may be N companies offering gateway services and that could increase the number of NAPTR records by an order of magnitude and create complexities for Client UA's on how to select a GW, not to mention pushing the DNS query into TCP. >When I talked with Patrik last week on this issue, he confirmed, that this >can be done (should be done?) also with CNAME Records. > >If this is the case, than I would propose only to use CNAME for this >purpose. I also propose the following for "tel:" >If a "tel:" is selected as the outcome of a query by the client on what >preference ever, NO additonal ENUM query SHALL be done, the "Tel: Number" >SHALL be used to set up a connection to this E.164 number, where ever it is >(contact address in SIP terminology). Do not forget, a E.164 number may also >terminate on IP (especially with h.323 ;-). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 11:37:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08145 for ; Sun, 17 Feb 2002 11:37:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15420 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 11:37:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14339; Sun, 17 Feb 2002 11:28:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14272 for ; Sun, 17 Feb 2002 11:28:22 -0500 (EST) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07946; Sun, 17 Feb 2002 11:28:18 -0500 (EST) Received: from user-2ivelt4.dialup.mindspring.com ([165.247.87.164] helo=dick.ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16cUAY-0004dR-00; Sun, 17 Feb 2002 11:28:07 -0500 Message-Id: <5.1.0.14.2.20020217111648.0234b0f8@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 17 Feb 2002 11:28:53 -0500 To: "'Patrik =?iso-8859-1?Q?F=E4ltstr=F6m=27?=" , "Peterson, Jon" , "'Kevin McCandless'" , "'enum@ietf.org'" From: Richard Shockey Subject: RE: [Enum] Using ENUM for SIP Applications Cc: sipping@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, dean.willis@softarmor.com In-Reply-To: <70565611B164D511957A001083FCDD56CAAF55@VA02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A >[snip] > > > > Should for example the flag in the NAPTR record differ between a SIP URI > > used for presence and one used for gaming and one used for voice calls? > > > > That MUST be resolved, I would say, before the registration document for > > SIP-related flags is finished. > >I agree totally. We present quite a few arguments for one perspective on >this matter in our document. While we don't go ahead and register any >SIP-related flags in the IANA considerations section, future versions of >this document are probably as good a place to register 'sip+E2U' as any. > >I'd be interested to know whether or not there is basically consensus, based >on the arguments that we've raised in sipping-e164-01, that we need no ENUM >service fields for SIP other than 'sip+E2U'. Maybe if we have time this is >something we could discuss in MN, at the discretion of the chairs. I think you can assume that there will be time on the ENUM WG agenda in MN for this document. There is obviously a lot of interest in this. We have a 2 1/2 hour slot .. and SIPPING has a lot on its plate. Now we have not cross posted these messages to SIPPING ...to avoid overburdening their totally overburdened list ... but we need to keep them in the loop and make sure they are aware of this discussion and that we probably will discuss the document in MN and that all SIPPING WG participants with an interest here might want to attend. I'm assuming this plan is OK with the SIPPING Chairs.... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 12:30:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08764 for ; Sun, 17 Feb 2002 12:30:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18161 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 12:30:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17743; Sun, 17 Feb 2002 12:21:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17707 for ; Sun, 17 Feb 2002 12:21:37 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08658 for ; Sun, 17 Feb 2002 12:21:33 -0500 (EST) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA09296; Sun, 17 Feb 2002 09:21:32 -0800 Message-Id: <5.1.0.14.2.20020217091734.0340f008@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 17 Feb 2002 09:20:14 -0800 To: Richard Shockey From: Dave Crocker Subject: Re: [Enum] SIpping-e164 comments Cc: Kevin McCandless , "'enum@ietf.org'" In-Reply-To: <5.1.0.14.2.20020217111137.023832e0@popd.ix.netcom.com> References: <1C1EEC765F843E44996971A80682118B014B0FC0@opwinex01.corp.il luminet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:16 AM 2/17/2002 -0500, Richard Shockey wrote: >I think the DNS community would prefer it referred to as a database >service and not as a directory service ..that is part of the problem the >DNS now faces. Directory has all sorts of specific meanings associated with it. Indeed, the word 'directory' needs to be banned from all discussions involving the DNS, except when saying what the DNS is NOT. Database is a relatively generic and safe term. However if one seeks ideal terminology, it probably is a good idea also to shy away from the word database, for fear of invoking a range of generalities that do not apply, such as fast update and the caching problem already noted. Lookup or Mapping are the two words that are most often used to clarify what the DNS actual is. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 12:44:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09018 for ; Sun, 17 Feb 2002 12:44:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19129 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 12:44:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18699; Sun, 17 Feb 2002 12:35:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18660 for ; Sun, 17 Feb 2002 12:35:34 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08829 for ; Sun, 17 Feb 2002 12:35:30 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1HKYn001256; Sun, 17 Feb 2002 12:34:49 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202172034.g1HKYn001256@nic-naa.net> To: Richard Shockey cc: Kevin McCandless , "'enum@ietf.org'" , brunner@nic-naa.net Subject: Re: [Enum] SIpping-e164 comments In-Reply-To: Your message of "Sun, 17 Feb 2002 11:16:03 EST." <5.1.0.14.2.20020217111137.023832e0@popd.ix.netcom.com> Date: Sun, 17 Feb 2002 12:34:49 -0800 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Rich, I've no idea what "ENUM can be a DNS directory service." means. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 13:02:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09278 for ; Sun, 17 Feb 2002 13:02:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20215 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 13:02:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19412; Sun, 17 Feb 2002 12:51:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19363 for ; Sun, 17 Feb 2002 12:51:55 -0500 (EST) Received: from yourwebsite.com (adsl-66-136-202-106.dsl.austtx.swbell.net [66.136.202.106]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09144 for ; Sun, 17 Feb 2002 12:51:52 -0500 (EST) From: RCPMailing@hotmail.com Message-Id: <200202171751.MAA09144@ietf.org> Reply-To: RCPMailing@hotmail.com To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 17 Feb 2002 11:52:12 -0600 Subject: [Enum] Receive $2 for every envelope you stuff for our company! Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Receive $2 for every envelope you stuff for our company! No experience required! Visit http://www.rcplanet.tv for more information! Regards, RCPM Staff This is a one time e-mail and you will not recieve any more e-mails from us. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 15:29:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10983 for ; Sun, 17 Feb 2002 15:29:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26107 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 15:29:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25780; Sun, 17 Feb 2002 15:18:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25749 for ; Sun, 17 Feb 2002 15:18:29 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10869 for ; Sun, 17 Feb 2002 15:18:24 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1HNHr001782; Sun, 17 Feb 2002 15:17:53 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202172317.g1HNHr001782@nic-naa.net> To: Richard Shockey , paf@paf.se cc: enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] sipping-e164 comments Date: Sun, 17 Feb 2002 15:17:53 -0800 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Co-chairs, Statements of the form: > BTW, I felt the need to point out the following statement in have limited utility in this venue. The urgency of the "contributor" is not a substitute for actual technical contribution. Please assist the ignorant in finding their fora, where ever _else_ that may be, no matter who the ignorant actually are. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 15:37:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11125 for ; Sun, 17 Feb 2002 15:37:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26920 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 15:37:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26093; Sun, 17 Feb 2002 15:28:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26065 for ; Sun, 17 Feb 2002 15:28:47 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10975 for ; Sun, 17 Feb 2002 15:28:43 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA25056; Sun, 17 Feb 2002 21:28:01 +0100 (MET) Date: Sun, 17 Feb 2002 21:28:01 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Eric Brunner-Williams in Portland Maine , Richard Shockey cc: enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] sipping-e164 comments Message-ID: <2175061.1013981281@[0.0.0.0]> In-Reply-To: <200202172317.g1HNHr001782@nic-naa.net> References: <200202172317.g1HNHr001782@nic-naa.net> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-17 15.17 -0800 Eric Brunner-Williams in Portland Maine wrote: > Statements of the form: > >> BTW, I felt the need to point out the following statement in > > have limited utility in this venue. The urgency of the "contributor" is > not a substitute for actual technical contribution. > > Please assist the ignorant in finding their fora, where ever _else_ that > may be, no matter who the ignorant actually are. Eric, sometimes pointing these things out help discussions. Sometimes ignoring the posting and only interfering if the discussion continues is better. In the case of the postings last week from various people on this subject which is _not_ part of what this mailing list is about I have not found them being disturbing enough. But, the people which are interested in discussing the policy of the US Government or any other government in the world can discuss it either in the fora that body has created for those discussions, or in ITU-T SG2. Regarding use of NAPTR for other kind of numbering plans than E.164, note that I have on my list of clearifications I wanted to know if people agreed with one item which clearifies how this is to be handled. I have no comments so far on that point. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 16:23:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11659 for ; Sun, 17 Feb 2002 16:23:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29012 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 16:23:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28416; Sun, 17 Feb 2002 16:14:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28362 for ; Sun, 17 Feb 2002 16:14:04 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11553; Sun, 17 Feb 2002 16:13:59 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1HLDAZ25181; Sun, 17 Feb 2002 13:13:10 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACM58632; Sun, 17 Feb 2002 13:13:16 -0800 (PST) Date: Sun, 17 Feb 2002 13:11:55 -0800 (Pacific Standard Time) From: Rohan Mahy To: Richard Shockey cc: "'Patrik =?iso-8859-1?Q?F=E4ltstr=F6m=27?=" , "Peterson, Jon" , "'Kevin McCandless'" , "'enum@ietf.org'" , , , Subject: RE: [Enum] Using ENUM for SIP Applications In-Reply-To: <5.1.0.14.2.20020217111648.0234b0f8@popd.ix.netcom.com> Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org discussing this in ENUM is fine by me. we can make an announcement during our first session. thanks, -rohan On Sun, 17 Feb 2002, Richard Shockey wrote: > A > >[snip] > > > > > > Should for example the flag in the NAPTR record differ between a SIP URI > > > used for presence and one used for gaming and one used for voice calls? > > > > > > That MUST be resolved, I would say, before the registration document for > > > SIP-related flags is finished. > > > >I agree totally. We present quite a few arguments for one perspective on > >this matter in our document. While we don't go ahead and register any > >SIP-related flags in the IANA considerations section, future versions of > >this document are probably as good a place to register 'sip+E2U' as any. > > > >I'd be interested to know whether or not there is basically consensus, based > >on the arguments that we've raised in sipping-e164-01, that we need no ENUM > >service fields for SIP other than 'sip+E2U'. Maybe if we have time this is > >something we could discuss in MN, at the discretion of the chairs. > > I think you can assume that there will be time on the ENUM WG agenda in MN > for this document. There is obviously a lot of interest in this. We have a > 2 1/2 hour slot .. and SIPPING has a lot on its plate. > > Now we have not cross posted these messages to SIPPING ...to avoid > overburdening their totally overburdened list ... but we need to keep them > in the loop and make sure they are aware of this discussion and that we > probably will discuss the document in MN and that all SIPPING WG > participants with an interest here might want to attend. > > I'm assuming this plan is OK with the SIPPING Chairs.... > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 > 1120 Vermont Ave NW Suite 400 Washington DC 20005 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 17:29:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12424 for ; Sun, 17 Feb 2002 17:29:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02242 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 17:29:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01844; Sun, 17 Feb 2002 17:20:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01815 for ; Sun, 17 Feb 2002 17:20:04 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12280 for ; Sun, 17 Feb 2002 17:19:59 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1I1JH002218; Sun, 17 Feb 2002 17:19:17 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202180119.g1I1JH002218@nic-naa.net> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: Eric Brunner-Williams in Portland Maine , Richard Shockey , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] sipping-e164 comments In-Reply-To: Your message of "Sun, 17 Feb 2002 21:28:01 +0100." <2175061.1013981281@[0.0.0.0]> Date: Sun, 17 Feb 2002 17:19:17 -0800 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Patrik, In my sip lab I've zone files for, name servers serving, and resolvers resolving . for a sip app (gratuitous plug for VOCAL here). I personally don't care what strings, in US-ASCII or HIGH-BOGON, are used for either "plotz" or "fizz". I'm confused by the language of your (1) and (2) (your note of the 15th), in (1) "ENUM" refers to a service, in (2) there are "ENUM-like mechanisms". Having spent most of my life in the OS trade, mechanism is what we do, service is a fiction we fob off on users. Not to be used interchangably. Is the name of the delegation in the e164.arpa domain "ENUM"? If so, OK. Delegation is the mechanism, e164.arpa the scope, there is a gratuitous syntax restriction on the labels, and possibly some other cruft. Are delegations in other domains "ENUM-like"? If so, is their ENUM-esque essence (a) delegation, (b) scope, (c) label syntax, (d) other Since I'm not responsible for a private numbering plan, or an iso3166 dns label space, or an ICANN dns label space, this is one area (touching on several sections) of 2916 that I don't have an _interoperable_implementors_ opinion on. Irresponsible comments by non-implementors are a dime a gross, as another WG experience shows. Your (6) is something I suggest isn't "security". A "data collection and data protection considerations" section could address the properties of the data, independent of the access and transport mechanism(s). Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 22:26:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16197 for ; Sun, 17 Feb 2002 22:26:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA14188 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 22:27:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13823; Sun, 17 Feb 2002 22:18:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13792 for ; Sun, 17 Feb 2002 22:18:02 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16117 for ; Sun, 17 Feb 2002 22:17:57 -0500 (EST) Received: from co7040exch001p.wins.lucent.com (h135-39-1-40.lucent.com [135.39.1.40]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1I3HxU22313 for ; Sun, 17 Feb 2002 22:17:59 -0500 (EST) Received: by co7040exch001p.milehi.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sun, 17 Feb 2002 20:17:58 -0700 Message-ID: <0096D8500C92D211BAEB0008C7F4906C05B1813A@co7040exch002u.milehi.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Peterson, Jon" , "Peterson, Jon" , "'Kevin McCandless'" , "'enum@ietf.org'" Subject: RE: [Enum] Using ENUM for SIP Applications Date: Sun, 17 Feb 2002 20:17:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA13793 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I view SIP (or LDAP) not as a service, but as a protocol. Protocols can be used to deliver a number of otherwise unrelated services. I agree with Patrick that we need to identify the service here... gaming, IM, live voice (telephone) or whatever. Similarly, LDAP may be used for white pages, yellow pages, application specific database access or any number of other things. There may be alternate protocols for the same service. In this way I view Tel and SIP as possible URLs returned, with different weightings, for the same service of live person-to-person voice communication. I would like this point clarified in the ENUM documents to be clear that registrations should be for services. Greg V. -----Original Message----- From: Patrik F�ltstr�m [mailto:paf@cisco.com] Sent: Sunday, February 17, 2002 3:04 AM To: Peterson, Jon; Peterson, Jon; 'Kevin McCandless'; 'enum@ietf.org' Subject: RE: [Enum] Using ENUM for SIP Applications --On 2002-02-16 18.47 -0600 "Peterson, Jon" wrote: > I'd be interested to know whether or not there is basically consensus, > based on the arguments that we've raised in sipping-e164-01, that we need > no ENUM service fields for SIP other than 'sip+E2U'. Maybe if we have > time this is something we could discuss in MN, at the discretion of the > chairs. Yes. MY personal immediate reaction is that it would be good for the client looking up NAPTR records to know what SIP URI is used for each family of services. For example: I (as a person) might have one SIP URI for presence information, one used for gaming, and one for telephony -- simply because I buy/get these services from different service providers, and just like with email, that implies different domain names in the URI. So, a client which is only interested in presence stuff, why open SIP connections to SIP URI's before knowing that SIP URI is not interesting at all? In some cases of course one "SIP" definition is enough, BUT, as soon as you have more than one "kind" of service and more than one SIP URI, I think more information in the flag is needed for faster call setup. paf _______________________________________________ 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 daemon@optimus.ietf.org Sun Feb 17 22:35:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17226 for ; Sun, 17 Feb 2002 22:35:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA15039 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 22:35:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA14255; Sun, 17 Feb 2002 22:27:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA14200 for ; Sun, 17 Feb 2002 22:27:02 -0500 (EST) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16200; Sun, 17 Feb 2002 22:26:57 -0500 (EST) Received: from user-2ivel9d.dialup.mindspring.com ([165.247.85.45] helo=dick.ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16ceRz-0001CZ-00; Sun, 17 Feb 2002 22:26:48 -0500 Message-Id: <5.1.0.14.2.20020217222000.044264f0@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 17 Feb 2002 22:28:59 -0500 To: Rohan Mahy From: Richard Shockey Subject: RE: [Enum] Using ENUM for SIP Applications Cc: =?iso-8859-1?Q?=22=27Patrik_F=E4ltstr=F6m=27=22?= , "Peterson, Jon" , "'Kevin McCandless'" , "'enum@ietf.org'" , , , In-Reply-To: References: <5.1.0.14.2.20020217111648.0234b0f8@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 01:11 PM 2/17/2002 -0800, Rohan Mahy wrote: >discussing this in ENUM is fine by me. we can make an announcement during >our first session. I'll be happy to make the announcement myself it you think that will help...I do want this as a joint effort. >thanks, >-rohan Thanks again Rohan ..I thought that's how you might feel ..though I want to make sure that Brian and Dean concur. I'm deeply sympathetic to the work load the SIPPING WG has but I want to make sure your WG and ours is properly informed at all stages of this discussion and that when this document or one that is similar to it comes to last call it will be a joint action between both WG's. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-01.txt BTW for those SIPPING folks who are scratching their heads wondering what this thread is all about . I'm the co-chair of the ENUM WG and if you need more info go to : http://www.ietf.org/html.charters/enum-charter.html >On Sun, 17 Feb 2002, Richard Shockey wrote: > > > A > > >[snip] > > > > > > > > Should for example the flag in the NAPTR record differ between a > SIP URI > > > > used for presence and one used for gaming and one used for voice calls? > > > > > > > > That MUST be resolved, I would say, before the registration > document for > > > > SIP-related flags is finished. > > > > > >I agree totally. We present quite a few arguments for one perspective on > > >this matter in our document. While we don't go ahead and register any > > >SIP-related flags in the IANA considerations section, future versions of > > >this document are probably as good a place to register 'sip+E2U' as any. > > > > > >I'd be interested to know whether or not there is basically consensus, > based > > >on the arguments that we've raised in sipping-e164-01, that we need no > ENUM > > >service fields for SIP other than 'sip+E2U'. Maybe if we have time this is > > >something we could discuss in MN, at the discretion of the chairs. > > > > I think you can assume that there will be time on the ENUM WG agenda in MN > > for this document. There is obviously a lot of interest in this. We have a > > 2 1/2 hour slot .. and SIPPING has a lot on its plate. > > > > Now we have not cross posted these messages to SIPPING ...to avoid > > overburdening their totally overburdened list ... but we need to keep them > > in the loop and make sure they are aware of this discussion and that we > > probably will discuss the document in MN and that all SIPPING WG > > participants with an interest here might want to attend. > > > > I'm assuming this plan is OK with the SIPPING Chairs.... > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 17 23:24:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17746 for ; Sun, 17 Feb 2002 23:24:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA16371 for enum-archive@odin.ietf.org; Sun, 17 Feb 2002 23:24:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA16167; Sun, 17 Feb 2002 23:15:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA16133 for ; Sun, 17 Feb 2002 23:15:48 -0500 (EST) Received: from yourwebsite.com (adsl-208-189-133-219.dsl.hstntx.swbell.net [208.189.133.219]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17667 for ; Sun, 17 Feb 2002 23:15:42 -0500 (EST) From: WC-4128@myhealthyamericacard.com Message-Id: <200202180415.XAA17667@ietf.org> Reply-To: WC-4128@myhealthyamericacard.com To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Sun, 17 Feb 2002 22:18:54 -0600 Subject: [Enum] (no subject) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Medical

 
Medical Problems?
Pre-Existing Medical Conditions?
Smoker?
Overweight?
Can't Qualify For Health Insurance?
Lost Your Job?
Do You Need Immediate Coverage?
 
Can You Afford $50.00 Per Month To Get No Out-Of-Pocket Family Coverage from the best PPO medical provider based discount services in the country? 

Click Here To Check It Out

Note: This e-mail is a one-time advertisement for an affordable PPO like health program sent from the source provider. It is not a bulk mail advertising program and is only being sent once. There is no need to remove this from any mailing list.  

 

The HealthyAmericaCard - The Next Best Thing To Insurance
_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Feb 18 05:54:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29934 for ; Mon, 18 Feb 2002 05:54:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA13133 for enum-archive@odin.ietf.org; Mon, 18 Feb 2002 05:54:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12664; Mon, 18 Feb 2002 05:43:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12636 for ; Mon, 18 Feb 2002 05:43:21 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29816 for ; Mon, 18 Feb 2002 05:43:16 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1IAgYJ14971; Mon, 18 Feb 2002 05:42:34 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4PV9>; Mon, 18 Feb 2002 04:42:29 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF6C@VA02> From: "Peterson, Jon" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: "'enum@ietf.org'" Subject: RE: [Enum] Using ENUM for SIP Applications Date: Mon, 18 Feb 2002 04:42:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I think these are exactly the respects in which SIP and ENUM are, to a small degree, competitive. ENUM could be used to provide service-specific URIs through more specific and detailed 'protocol' or 'resolution service' subfields of the service field. SIP of course has its own way of figuring out where requests should be directed and what communications services should be invoked for a session,. Where does ENUM stop and SIP begin when you're trying to figure out how to communicate? This is the entire question explored by our draft, which has a good amount of analysis of the two protocols, but I'll speak briefly to this point here as well. Agreed that if you have more than one SIP URI in ENUM, then if no means of differentiation are provided, then this leads to a potentially awkward and slow mechanism of selecting a proper NAPTR record. This could lead one to draw one of two conclusions: 1) that you need differentiation of service fields, or 2) that you should use only one SIP URI in ENUM. This is the issue on which the people who are implementing ENUM for SIP must arrive at consensus. ENUM works best, I think, if, before you send a SIP request to a remote endpoint, you already know what kind of session you want to have - presence, instant messaging, telephony, video, etc. However, SIP does not require you to decide on a communications service before you send an INVITE. Rather, it lets you express your capabilities in an INVITE, and then to negotiate with the target user which set of those communications services, if any, you should employ for a session. I think it is in fact when you have multiple "kinds" of service that SIP's capability negotiation really has an advantage. Agreed that it is possible to have a single communications service in mind (like, say, instant messaging) you would like to employ before you send a SIP request. Some would argue that many SIP devices support only a single communications service (although I believe the most common one today supports many such communications services by default). But even if you get particular communications services from different service providers, SIP has its own mechanisms for properly directing requests for communication that provide, in my estimation, a bit more sophistication than is available from the service fields of NAPTR records. In a previous note I talked a bit about the benefits of managing devices at a real-time location service rather than in the DNS. It is because of the loss of these real-time features, and the full capability negotiation services of SIP, that it has been argued by some people in the SIP community that composing services this way in ENUM actually deprives SIP of capability. If you discover that a particular communications service is available through an ENUM service field, SIP still needs to do further capability negotiations that will ultimately determine how and if a session can be established with the target of a URI. For example, if we learned that a URI supported voice from a hypothetical E2VOICE record, we still wouldn't know what codecs are supported, and further SIP negotiation is required to determine whether or not we have any in common (without an 'E2VOICE-G711' resolution service and all the permutations that would entail). It is also problematic to express multiple communications services simultaneously in the service field (video streams will commonly be negotiated simultaneously with voice streams - if all of the possible concurrent combinations of communications services need to be flagged simultaneously in the service field, interpreting the field could become quite complex and the IANA registry quite lengthy). Similarly, support for extensions (the Required/Supported) mechanisms determines whether or not two endpoints can communicate, but expressing extension support in the service field probably isn't feasible. Incorporating this into ENUM would be very difficult, but fortunately it is totally unnecessary if you defer request routing and capability negotiation to SIP. I'm afraid we may only build partial overlap with SIP, rather than new features, into ENUM by creating complex service fields. A more detailed exploration of these points is given in the draft, especially in sections 3.4 and 3.5. Finally, let me say that I am only arguing that the above applies for SIP - I have no idea if this sort of argument makes sense for other protocols that are brokered by ENUM. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Patrik F�ltstr�m [mailto:paf@cisco.com] > Sent: Sunday, February 17, 2002 1:04 AM > To: Peterson, Jon; Peterson, Jon; 'Kevin McCandless'; 'enum@ietf.org' > Subject: RE: [Enum] Using ENUM for SIP Applications > [snip] > > MY personal immediate reaction is that it would be good for the client > looking up NAPTR records to know what SIP URI is used for > each family ofservices. > > For example: I (as a person) might have one SIP URI for presence > information, one used for gaming, and one for telephony -- simply because I > buy/get these services from different service providers, and just like with > email, that implies different domain names in the URI. > > So, a client which is only interested in presence stuff, why open SIP > connections to SIP URI's before knowing that SIP URI is not > interesting at > all? > > In some cases of course one "SIP" definition is enough, BUT, as soon as you > have more than one "kind" of service and more than one SIP URI, I think > more information in the flag is needed for faster call setup. > > paf > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Feb 18 12:30:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10131 for ; Mon, 18 Feb 2002 12:30:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02195 for enum-archive@odin.ietf.org; Mon, 18 Feb 2002 12:30:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01693; Mon, 18 Feb 2002 12:21:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01665 for ; Mon, 18 Feb 2002 12:21:19 -0500 (EST) Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09764 for ; Mon, 18 Feb 2002 12:21:08 -0500 (EST) Received: from RWALTER ([65.203.166.26]) by hvmta01-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020218172041.IIWY21209.hvmta01-stg.us.psimail.psi.net@RWALTER>; Mon, 18 Feb 2002 12:20:41 -0500 Reply-To: From: "Robert H. Walter" To: "Peterson, Jon" Cc: Subject: RE: [Enum] Using ENUM for SIP Applications Date: Mon, 18 Feb 2002 12:21:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <70565611B164D511957A001083FCDD56CAAF6C@VA02> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Hi Jon, I would also like to thank you and the authors for a well written Internet draft... [snip] > Agreed that if you have more than one SIP URI in ENUM, then if no means of > differentiation are provided, then this leads to a potentially awkward and > slow mechanism of selecting a proper NAPTR record. This could lead one to > draw one of two conclusions: 1) that you need differentiation of service > fields, or 2) that you should use only one SIP URI in ENUM. This is the > issue on which the people who are implementing ENUM for SIP must arrive at > consensus. If I understand you correctly, you are recommending option "2" and that all SIP communications service discovery be performed via the SIP protocol. This approach simply moves the "awkward and slow mechanism" of selecting the appropriate communications service into the SIP protocol or limits the ability of SIP to support multiple service providers for a single telephone number. Certainly the requesting application knows the type of communications session it wishes to establish (i.e. Voice, Instant Messaging, etc.) prior to sending the SIP request. The "ENUM Resolution Protocols and Services" I-D proposes a solution for unambiguously locating a SIP communications service from multiple service providers through the definition of new ENUM resolution services like E2VOICE, E2IM, etc. This prior knowledge can be used to avoid an "awkward and slow mechanism" and quickly establish the AoR associated with the communications service. Establishing the service provider specific AoR prior to the SIP request greatly facilitates SIP based capability negotiation between two interested parties that's more likely than not, to result in a successful session. For those of you who have not read "ENUM Resolution Protocols and Services" it is available at: http://www.ietf.org/internet-drafts/draft-walter-ranalli-enum-service-01.txt Bob Walter NetNumber, Inc. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Feb 18 14:25:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14634 for ; Mon, 18 Feb 2002 14:25:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06877 for enum-archive@odin.ietf.org; Mon, 18 Feb 2002 14:25:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06491; Mon, 18 Feb 2002 14:15:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06460 for ; Mon, 18 Feb 2002 14:15:53 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14224 for ; Mon, 18 Feb 2002 14:15:48 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1IJFK001122; Mon, 18 Feb 2002 13:15:21 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4R5F>; Mon, 18 Feb 2002 13:15:15 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAF70@VA02> From: "Peterson, Jon" To: "'rwalter@netnumber.com'" Cc: enum@ietf.org Subject: RE: [Enum] Using ENUM for SIP Applications Date: Mon, 18 Feb 2002 13:15:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Thanks for your comments, Mr. Walter. A few notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Robert H. Walter [mailto:rwalter@netnumber.com] > Sent: Monday, February 18, 2002 9:21 AM > To: Peterson, Jon > Cc: enum@ietf.org > Subject: RE: [Enum] Using ENUM for SIP Applications > [snip] > This approach simply moves the "awkward and slow mechanism" of selecting the > appropriate communications service into the SIP protocol or limits the > ability of SIP to support multiple service providers for a single telephone > number. Yes, it does move this mechanism back into SIP. I do not believe that doing so in any way limits or degrades SIP's abilities. On the contrary, it reinvests SIP with powers that would be lost if we were attempting to negotiate capabilities from within ENUM. > > Certainly the requesting application knows the type of communications session > it wishes to establish (i.e. Voice, Instant Messaging, etc.) prior to sending > the SIP request. I do not find this at all certain. In fact, what I see in the SIP/SDP protocol suite is a system that allows me to express my capabilities to a target user, and subsequently to negotiate common ways to communicate, one or more of which will be used in a session. Those who are looking to paint ENUM in a favorable light for SIP usage must, I would hope, be aware of the services that SIP/SDP provides. SIP has a user location system. SIP has a capability negotiation system. These are not add-ons to SIP, these are the core things that SIP does. It locates a target user and finds the best way to communicate with them in a session (which is carried out by some other protocol). Providing rudimentary competition to these services within ENUM will not improve on the capabilities of a combined ENUM/SIP system, it will just make it unclear to implementers where ENUM leaves off and SIP begins. ENUM provides a way to turn E.164 numbers into URIs, ones that might be used as an input to SIP's process. I'm not sure why we need to somehow expand ENUM's scope beyond that - I like it just the way it is. IMHO, this is really somewhat academic. If the advocates of ENUM insist on a view of ENUM that mindfully limits the capabilities of SIP, then in the long term SIP usage will not drive the adoption of ENUM. If on the other hand a case is made for ENUM that is genuinely beneficial to SIP, then this will be a win for both the ENUM and SIP camps down the road. > Bob Walter > NetNumber, Inc. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Feb 18 16:20:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18964 for ; Mon, 18 Feb 2002 16:20:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12945 for enum-archive@odin.ietf.org; Mon, 18 Feb 2002 16:20:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12529; Mon, 18 Feb 2002 16:11:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12498 for ; Mon, 18 Feb 2002 16:11:51 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18626 for ; Mon, 18 Feb 2002 16:11:47 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA09063; Mon, 18 Feb 2002 22:11:12 +0100 (MET) Date: Mon, 18 Feb 2002 21:28:35 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Peterson, Jon" cc: "'enum@ietf.org'" Subject: RE: [Enum] Using ENUM for SIP Applications Message-ID: <3361151.1014067715@localhost> In-Reply-To: <70565611B164D511957A001083FCDD56CAAF6C@VA02> References: <70565611B164D511957A001083FCDD56CAAF6C@VA02> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-18 04.42 -0600 "Peterson, Jon" wrote: > Finally, let me say that I am only arguing that the above applies for SIP > - I have no idea if this sort of argument makes sense for other protocols > that are brokered by ENUM. Probably many. This is one of the strongest arguments why I think separate documents which talk about each one of the protocols. I only have one input to your text: I think it will be impossible to tell people to only have one SIP URI in ENUM. Reason for that is because one will probably have access to more than one SIP server (one private and one in the office for example) and I bet that some operators refuse to add information about the other. I.e. I have more than one email address, and will probably have more than one SIP URI. Hmmmm....I think I already have three when thinking about it out of which only one is reachable over the public Internet ;-) So, I would like to rephrase what you wrote by asking: If one have two SIP URI's, should there be any differentiation between them in the NAPTR? Not even if they are used for different "services" (whatever that means)? paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Feb 18 17:12:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18971 for ; Mon, 18 Feb 2002 16:20:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12959 for enum-archive@odin.ietf.org; Mon, 18 Feb 2002 16:20:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12568; Mon, 18 Feb 2002 16:12:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12539 for ; Mon, 18 Feb 2002 16:12:01 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18628 for ; Mon, 18 Feb 2002 16:11:57 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA09059; Mon, 18 Feb 2002 22:11:09 +0100 (MET) Date: Mon, 18 Feb 2002 21:22:35 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Vaudreuil, Greg M (Greg)" , "Peterson, Jon" , "Peterson, Jon" , "'Kevin McCandless'" , "'enum@ietf.org'" Subject: RE: [Enum] Using ENUM for SIP Applications Message-ID: <3339537.1014067355@localhost> In-Reply-To: <0096D8500C92D211BAEB0008C7F4906C05B1813A@co7040exch002u.milehi.lucent.com> References: <0096D8500C92D211BAEB0008C7F4906C05B1813A@co7040exch002u.milehi. lucent.com> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-17 20.17 -0700 "Vaudreuil, Greg M (Greg)" wrote: > I would like this point clarified in the ENUM documents to be clear that > registrations should be for services. Point taken. I will try to create a drafty-drafty-draft version of 2916 before the cut-off for the IETF. Regardless of whether I manage to do so, I really want people to in the future send in _text_ that corrects misunderstandings in the text I write. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Feb 18 17:25:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20948 for ; Mon, 18 Feb 2002 17:25:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA16190 for enum-archive@odin.ietf.org; Mon, 18 Feb 2002 17:25:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15791; Mon, 18 Feb 2002 17:16:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15760 for ; Mon, 18 Feb 2002 17:16:08 -0500 (EST) Received: from yahoo.com ([203.94.243.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20637 for ; Mon, 18 Feb 2002 17:16:01 -0500 (EST) From: youcherry@yahoo.com Message-Id: <200202182216.RAA20637@ietf.org> Reply-To: youcherry@yahoo.com To: enum@ietf.org Date: 18 Feb 2002 22:48:24 GMT MIME-Version: 1.0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Enum] Take me. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit


Can you break my cherry?

Click Here and give it a try...

Little sluts are waiting for your big dick!
What are you waiting for?

HERE
















Note: this is not a spam email. This email was sent to you because your email was entered in on a website requesting to be a registered subscriber. If you did not request this email, please just answer on this mail.


_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Feb 18 21:07:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26760 for ; Mon, 18 Feb 2002 21:07:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA27122 for enum-archive@odin.ietf.org; Mon, 18 Feb 2002 21:07:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26360; Mon, 18 Feb 2002 20:58:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26329 for ; Mon, 18 Feb 2002 20:58:18 -0500 (EST) Received: from bfgbhome.inetint.com (IDENT:root@tnt-dal-42-220.dallas.net [209.44.42.220]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26612 for ; Mon, 18 Feb 2002 20:58:12 -0500 (EST) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id TAA19159 for enum@ietf.org; Mon, 18 Feb 2002 19:58:14 -0600 Date: Mon, 18 Feb 2002 19:58:14 -0600 From: "Brian F. G. Bidulock" To: enum@ietf.org Subject: Re: [Enum] Take me. Message-ID: <20020218195814.E15127@openss7.org> Reply-To: bidulock@openss7.org Mail-Followup-To: enum@ietf.org References: <200202182216.RAA20637@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200202182216.RAA20637@ietf.org>; from youcherry@yahoo.com on Mon, Feb 18, 2002 at 10:48:24PM +0000 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Was this an example of a service-specific URI? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Feb 18 23:32:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01310 for ; Mon, 18 Feb 2002 23:32:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA02310 for enum-archive@odin.ietf.org; Mon, 18 Feb 2002 23:32:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA01639; Mon, 18 Feb 2002 23:23:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA01608 for ; Mon, 18 Feb 2002 23:23:37 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00806 for ; Mon, 18 Feb 2002 23:23:32 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id FAA10531; Tue, 19 Feb 2002 05:23:03 +0100 (MET) Date: Tue, 19 Feb 2002 05:22:33 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: bidulock@openss7.org, enum@ietf.org Subject: Re: [Enum] Take me. Message-ID: <5067406.1014096153@localhost> In-Reply-To: <20020218195814.E15127@openss7.org> References: <200202182216.RAA20637@ietf.org> <20020218195814.E15127@openss7.org> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-18 19.58 -0600 "Brian F. G. Bidulock" wrote: > Was this an example of a service-specific URI? As wg chair I will have a spam-discussion with the people running the mailing list. Sigh... If I at the end come to a conclusion that the following is what we can do: - Subscribed people can post automatically - Non-subscribes postings must be moderated manually ...can I have people which can help doing the moderation? Please... paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 07:07:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15117 for ; Tue, 19 Feb 2002 07:07:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01022 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 07:07:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00081; Tue, 19 Feb 2002 06:57:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00050 for ; Tue, 19 Feb 2002 06:57:40 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14651 for ; Tue, 19 Feb 2002 06:57:39 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA11517; Tue, 19 Feb 2002 12:57:33 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA05606; Tue, 19 Feb 2002 12:57:27 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id <1JWYB7F0>; Tue, 19 Feb 2002 12:57:34 +0100 Message-ID: From: Brandner Rudolf To: enum@ietf.org Cc: "'michael@research.netsol.com'" , Conroy Lawrence Date: Tue, 19 Feb 2002 12:57:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Enum] DDDS, DNS clarification needed? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Having read the DDDS part 1, 2 and 3, I have some questions about ENUM, DNS and DDDS. My understanding of DDDS and ENUM is ENUM == a DDDS Application Follwing the example in draft-ietf-urn-dns-ddds-database-07.txt: 1) I have got a number +49-8141-5359799 2) The AUS would be +4981415359799 3) The First Well Known Rule would yield the First Key 4981415359799 4) In order to use DNS the First Key is converted into a domain-name "9.9.7.9.5.3.5.1.4.1.8.9.4.e164.arpa." 5) Retrieve Rewrite Rules as NAPTR records using key 6) Apply NAPTR on AUS to produce a new key 7) If matching rule is terminal we have the result, else goto step 5 with this key Questions: - Shouldn't step 4 be part of the First Well Known Rule according to the algorithm diagram of draft-ietf-urn-ddds-05.txt, Page 6? - If step 4 is not part of the First Well Known Rule, where does it fit into the algorithm diagram? - The algorithm diagram in DDS-05 does not describe lookups that result in a NS record (through delegation). This means that it expects to use a Recursive Resolver? Many thanks for the clarifications, Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 08:03:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16885 for ; Tue, 19 Feb 2002 08:03:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03782 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 08:03:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02993; Tue, 19 Feb 2002 07:55:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02962 for ; Tue, 19 Feb 2002 07:55:02 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16547 for ; Tue, 19 Feb 2002 07:55:00 -0500 (EST) Received: from [193.118.192.40] ([193.118.192.40] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062594; Tue, 19 Feb 2002 12:54:59 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: In-Reply-To: References: Date: Tue, 19 Feb 2002 12:54:55 +0000 To: Rudolf Brandner From: Lawrence Conroy Subject: Re: [Enum] DDDS, DNS clarification needed? Cc: enum@ietf.org, "'michael@research.netsol.com'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 12:57 pm +0100 19/2/02, Brandner Rudolf wrote: >Having read the DDDS part 1, 2 and 3, I have some questions about >ENUM, DNS and DDDS. > >My understanding of DDDS and ENUM is > ENUM == a DDDS Application > >Follwing the example in draft-ietf-urn-dns-ddds-database-07.txt: > >1) I have got a number +49-8141-5359799 >2) The AUS would be +4981415359799 >3) The First Well Known Rule would yield the First Key 4981415359799 >4) In order to use DNS the First Key is converted into a domain-name > "9.9.7.9.5.3.5.1.4.1.8.9.4.e164.arpa." >5) Retrieve Rewrite Rules as NAPTR records using key >6) Apply NAPTR on AUS to produce a new key >7) If matching rule is terminal we have the result, > else goto step 5 with this key > >Questions: > >- Shouldn't step 4 be part of the First Well Known Rule according to >the algorithm diagram of draft-ietf-urn-ddds-05.txt, Page 6? > >- If step 4 is not part of the First Well Known Rule, where does it >fit into the algorithm diagram? > >- The algorithm diagram in DDS-05 does not describe lookups that >result in a NS record (through delegation). This means that it >expects to use a Recursive Resolver? > > >Many thanks for the clarifications, >Rudi > To which I add more questions on the TripleDS thicket: Question - is the AUS "+494023451234" or is it "494023451234"? Question - Does the conversion of the AUS to a key (using the "First Well Known Rule") give "494023451234" or instead give us "4.3.2.1.5.4.3.2.0.4.9.4"? Question - Should the process of converting a key to DNS-suitable form append a "well known constant" domain (e.g. ENUM_ROOT_DOMAIN), rather than "hard-wiring" the domain? The value of this constant is ".e164.arpa.", of course, and it *is* a generalisation, but this may be useful in the future. Question - Application Collision Avoidance seems to be achieved by placing the DNS queries in the ENUM_ROOT_DOMAIN; does this mean that we CANNOT place NAPTRs for other application types (e.g URN resolution) in zones within this space (i.e. all NATPRs under ENUM_ROOT_DOMAIN *MUST* be ENUM rules)? All the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 09:03:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18922 for ; Tue, 19 Feb 2002 09:03:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06856 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 09:03:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05966; Tue, 19 Feb 2002 08:54:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05937 for ; Tue, 19 Feb 2002 08:54:29 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18352 for ; Tue, 19 Feb 2002 08:54:26 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1JDrZ024311; Tue, 19 Feb 2002 07:53:35 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7F4V9V>; Tue, 19 Feb 2002 07:53:30 -0600 Message-ID: <70565611B164D511957A001083FCDD56018700D5@VA02> From: "Peterson, Jon" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: "'enum@ietf.org'" Subject: RE: [Enum] Using ENUM for SIP Applications Date: Tue, 19 Feb 2002 07:53:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA05938 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Interesting questions. Some lengthy notes below. Those interested only in the conclusions can just read the last paragraph. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Patrik F�ltstr�m [mailto:paf@cisco.com] > Sent: Monday, February 18, 2002 12:29 PM > To: Peterson, Jon > Cc: 'enum@ietf.org' > Subject: RE: [Enum] Using ENUM for SIP Applications > [snip] > > I only have one input to your text: I think it will be impossible to tell > people to only have one SIP URI in ENUM. Reason for that is because one > will probably have access to more than one SIP server (one private and one > in the office for example) and I bet that some operators refuse to add > information about the other. > First of all, I agree that we cannot mandate absolutely that authors of records will place only one SIP URI in ENUM. What we can do, though, is acknowledge that there are currently two lines of thought on this matter, show what the strengths and weaknesses are of the two positions and, if possible, recommend one practice or the other. That is what we set out to do in the sipping-e164 draft. Now, I want to be careful here - this is a complicated point. Clearly, users of SIP can and probably should have multiple identities, just as today we have multiple identities for email. However, SIP identities (which are expressed in URIs as addresses-of-record or AoRs) do not have capabilities. SIP devices (like user agents) have specific capabilities (corresponding to specific communications services, like, G.711 mu-law audio at 10ms interval). A device may register under one or more identities, and an identity may have multiple devices registered under it simultaneously. However, registration is not a permanent association, and the protocol effects of a SIP registration should be managed in SIP, not in the DNS. Complications arise when we begin to postulate that particular service providers will want to restrict the traditional capabilities of SIP. So for example, imagine you have have a 'home' identity and a 'work' identity, and then a SIP device, a wireless phone. SIP traditionally allows devices to roam between administrative domains: while you're at work, your wireless phone is registered under your work identity, while at home it registers under your home identity. But then in some possible administrative models, as you suggest, user agents might only be able to register in a particular domain (and consequently under a particular identity). In fact, some restrictive service providers could create a rigid one-to-one correspondence between an identity and a single device - however, if they do so, as an aside I'd like to point out that the value of using a URI (and much of the value of SIP) is largely lost, and you might as well just use an IPv4 address instead. All that said, I don't think the fact that users will have multiple SIP identities in and of itself has much bearing on whether or not a single URI or multiple URIs should go into ENUM. Differentiating between multiple identities like 'work' and 'home' in ENUM would be quite difficult; I mean, we can't use "SIP+E2HOME" and "SIP+E2WORK" to differentiate URIs (where choosing between service fields requires human oversight). What has been suggested for differentiation is that the capabilities associated with a URI should be advertised in the service field (i.e "SIP+E2VOICE") so that a URI can be programmatically chosen by the querying user agent. But this makes the assumption that a URI has capabilities, and that's where things get a little murky for me. When you want to get in touch with a user with SIP, what's important is that you can contact the devices at which the user is available. In the example above, the wireless phone I described can register under both the 'home' and 'work' identity. If the phone is registered under a particular identity, and that identity receives a call setup request, the phone can ring. Now, this wireless phone might support voice (with a particular set of low-bandwidth codecs), instant messaging, and maybe other capabilities. It's only when such a device is registered with these identities that these identities are able to participate in any kind of session. This registration automatically causes changes in the state of a SIP service that will allow appropriate SIP requests to be routed to the device. I think it ultimately doesn't really matter, from a capability perspective, which identity I put into ENUM, provided that the appropriate set of devices are registered under the identity when someone tries to communicate with it - I think this is my biggest disconnect with a lot of the arguments I hear about how ENUM and SIP should work together. In vanilla SIP, nothing precludes any device from registering under any identity. Ultimately, which identity I associate with an ENUM record is probably more of a concern about perception. ENUM records are accessed with a telephone number, and the usage of that telephone number might suggest something about the identity you should place in ENUM for SIP. For a work telephone number, a 'work' identity might be more appropriate than a personal identity that highlights your love of Star Trek. It also might not be important to you that certain devices are reachable through certain ENUM records (like my work fax device being available at the ENUM record corresponding to my home phone number). But now let's look at the troublesome case in which a user insists on having all devices associated with all of their identities available through a single ENUM record. How can this work with the hypothetical restrictive service provider who creates a rigid one-to-one mapping between a device and an identity? Say for example that your 'work' identity is associated with a particular device, an instant messaging client, that could only register with your 'work' identity - but, some other devices that you use (like your Quake client) are not allowed to register at your 'work' identity. That seems to suggest that you need two identities in ENUM in order for all of your devices to be reachable. This would only be true if it were impossible to register an identity beneath another identity. In order to make every device that you control available through a single URI when some devices have restricted usage, you could register your 'work' identity under your 'home' identity, and then treat your home identity as a master AoR which you would then put into ENUM. All you need are the proper credentials to register devices under your 'home' identity, and the URI of your 'work' identity - it does not require the administrative domain responsible for your 'work' identity to be complicit in any way (in fact, there's nothing they can do about it if they try, probably). Your 'work' identity ostensibly becomes a contact address for the instant messaging client that it manages; like any other contact address it can register and deregister from the 'home' identity as needed over time. It is important to remember that sometimes (perhaps usually?), SIP services will be requested without any prior ENUM query, presumably by a caller that already knows the AoR of the target user. Thus, any service managing an AoR will always have a way of reaching relevant devices associated with the requested URI anyway. This suggests strongly to me that any identities and devices will have to be composed in a SIP service somewhere, regardless of how we slice up this problem in ENUM. If however we must replicate the availability of identities/device in SIP and ENUM, the two run the risk of getting out of sync, management becomes more difficult, and so on. I believe that it is probably more reasonable to compose services in a single service; namely in SIP, because (as I argued in a mail yesterday) SIP has deeper capability negotiation and user location systems. Whether or not using ENUM service fields to characterize services is 'faster' than what would happen without the service fields really isn't material - SIP capability negotiation still needs to take place even when E2VOICE-style service fields are used, and I don't believe that even registering identities under other identities will lead to substantial degradation in performance. Further analysis on this point would probably take another (equally long) email, though I'd be happy to detail this later if anyone finds my reasoning here particularly contentious. But returning to the troublesome cases, what if your 'home' identity doesn't allow arbitrary registrations either, so you can't register your 'work' identity under it? Why should I necessarily think that any service providers will allow arbitrary registrations, or that such services will be commonly available? Well, I own a couple of SIP devices today, and none of them are bound inextricably to any particular service, but let's imagine for a moment that dystopian future. Ultimately, the answer is that identities in the Internet are not exactly at a premium. I believe that SIP address-of-record URIs will be free and plentiful, for the same reasons that email addresses are free and plentiful. Like the web or email, in order to be a SIP 'service provider' you need nothing more than a domain, some connectivity and a box; a SIP registrar/redirect service would be a less intensive venture than, say, hotmail.com. I believe that it will always be possible to acquire such an AoR and to register any walled-garden 'home' and 'work' identities beneath it, and then put this 'master' AoR in ENUM. So, to sum up, I agree that SIP users can and will have multiple identities. However, choosing which identity to place in ENUM is, I think, unrelated to the 'E2VOICE'-style capability negotiation question. Devices register under identities, and it is devices that have capabilities; registration is a SIP protocol mechanism, and its effects should be managed in SIP, not in DNS. Identities are, as you suggested, things like 'work' and 'home'. Although there may also be identities that are bound by a service provider to a specific service, these identities can be treated as contact addresses and composed under other, 'master' identities. I think we can make a good case that indexing multiple identities by capability in ENUM degrades the capabilities of SIP. For that reason, I think we can argue that we should recommend placing only a single SIP URI in an ENUM record. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 09:29:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20579 for ; Tue, 19 Feb 2002 09:29:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08021 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 09:29:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07492; Tue, 19 Feb 2002 09:20:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07429 for ; Tue, 19 Feb 2002 09:20:28 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20151 for ; Tue, 19 Feb 2002 09:20:25 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1JEGCI2029250; Tue, 19 Feb 2002 09:16:13 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1JEG9qT029249; Tue, 19 Feb 2002 09:16:09 -0500 (EST) Date: Tue, 19 Feb 2002 09:16:09 -0500 From: Michael Mealling To: Brandner Rudolf Cc: enum@ietf.org, "'michael@research.netsol.com'" , Conroy Lawrence Message-ID: <20020219091609.K26811@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Subject: [Enum] Re: DDDS, DNS clarification needed? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Tue, Feb 19, 2002 at 12:57:08PM +0100, Brandner Rudolf wrote: > Having read the DDDS part 1, 2 and 3, I have some questions about ENUM, > DNS and DDDS. > > My understanding of DDDS and ENUM is > ENUM == a DDDS Application Correct... > Follwing the example in draft-ietf-urn-dns-ddds-database-07.txt: > > 1) I have got a number +49-8141-5359799 > 2) The AUS would be +4981415359799 > 3) The First Well Known Rule would yield the First Key 4981415359799 > 4) In order to use DNS the First Key is converted into a domain-name > "9.9.7.9.5.3.5.1.4.1.8.9.4.e164.arpa." > 5) Retrieve Rewrite Rules as NAPTR records using key > 6) Apply NAPTR on AUS to produce a new key > 7) If matching rule is terminal we have the result, > else goto step 5 with this key > > Questions: > > - Shouldn't step 4 be part of the First Well Known Rule according to the > algorithm diagram of draft-ietf-urn-ddds-05.txt, Page 6? Not really. I can see where the question comes from though. That diagram is generic for all databases/applications. There is a database specific step where the Key is converted into database specific form. In the Database specification this is the 'Key Format'. > - If step 4 is not part of the First Well Known Rule, where does it fit > into the algorithm diagram? It is the conversion step from the generic application into the Database specific form. I.e. this ENUM step is actually all part of the "Lookup key in DDDS Database" block in that diagram. > - The algorithm diagram in DDS-05 does not describe lookups that result > in a NS record (through delegation). This means that it expects to use a > Recursive Resolver? Correct. The DNS Database simply returns requests for Keys in the correct Format according to the existing DNS standards. Thus, the algorithm simply asks for "9.9.7.9.5.3.5.1.4.1.8.9.4.e164.arpa.", it is up to the DNS resolver to handle all DNS specific NS processes and other standard techniques. The reason all of this is this way is that you could just as easily specify in the future that ENUM use another directory. Let's suppose that in a few months we come up with some new DNS software that makes the existing system obsolete (shudder). All you would need to do is specify how the Key in #3 is expressed in that new Database and then what the output record format was. The algorithm, APIs, policies, etc can all stay the same. One example was in the URI Resolution application. There was a need for having cached records in a local file on a CDROM. The authors simply specified a new database that worked on flat files with very simple keys. The algorithms and APIs 'just worked', all they had to do is switch out which database they were using depending on whether or not they were connected to the Internet or not. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 09:40:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21123 for ; Tue, 19 Feb 2002 09:40:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA09274 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 09:40:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08622; Tue, 19 Feb 2002 09:31:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08505 for ; Tue, 19 Feb 2002 09:31:16 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20660 for ; Tue, 19 Feb 2002 09:31:12 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1JEQvI2029314; Tue, 19 Feb 2002 09:26:58 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1JEQrVa029313; Tue, 19 Feb 2002 09:26:53 -0500 (EST) Date: Tue, 19 Feb 2002 09:26:53 -0500 From: Michael Mealling To: Lawrence Conroy Cc: Rudolf Brandner , enum@ietf.org, "'michael@research.netsol.com'" Subject: Re: [Enum] DDDS, DNS clarification needed? Message-ID: <20020219092653.L26811@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Tue, Feb 19, 2002 at 12:54:55PM +0000, Lawrence Conroy wrote: > At 12:57 pm +0100 19/2/02, Brandner Rudolf wrote: > >Having read the DDDS part 1, 2 and 3, I have some questions about > >ENUM, DNS and DDDS. > > > >My understanding of DDDS and ENUM is > > ENUM == a DDDS Application > > > >Follwing the example in draft-ietf-urn-dns-ddds-database-07.txt: > > > >1) I have got a number +49-8141-5359799 > >2) The AUS would be +4981415359799 > >3) The First Well Known Rule would yield the First Key 4981415359799 > >4) In order to use DNS the First Key is converted into a domain-name > > "9.9.7.9.5.3.5.1.4.1.8.9.4.e164.arpa." > >5) Retrieve Rewrite Rules as NAPTR records using key > >6) Apply NAPTR on AUS to produce a new key > >7) If matching rule is terminal we have the result, > > else goto step 5 with this key > > > >Questions: > > > >- Shouldn't step 4 be part of the First Well Known Rule according to > >the algorithm diagram of draft-ietf-urn-ddds-05.txt, Page 6? > > > >- If step 4 is not part of the First Well Known Rule, where does it > >fit into the algorithm diagram? > > > >- The algorithm diagram in DDS-05 does not describe lookups that > >result in a NS record (through delegation). This means that it > >expects to use a Recursive Resolver? > > > > > >Many thanks for the clarifications, > >Rudi > > > To which I add more questions on the TripleDS thicket: > Question - is the AUS "+494023451234" or is it "494023451234"? The AUS is the second one. The '+' is extraneous here so its removed to make the Key as simple as possible but still useable. > Question - Does the conversion of the AUS to a key (using the > "First Well Known Rule") give "494023451234" or instead give us > "4.3.2.1.5.4.3.2.0.4.9.4"? It gives "494023451234". Its the conversion of that Key into the Database Key Format that gives the dotted, DNS form. > Question - Should the process of converting a key to DNS-suitable > form append a "well known constant" domain (e.g. ENUM_ROOT_DOMAIN), > rather than "hard-wiring" the domain? > The value of this constant is ".e164.arpa.", of course, and it *is* > a generalisation, but this may be useful in the future. I'm not going to go there! ;-) You could do that but IMHO changing your root around like that is asking for insane amounts of trouble. Define ENUM as e164.arpa and be done with it. If you want to do something else in another root then call it something else: FooNum, BarNum, FooBlat Telephone Number Lookup Service. > Question - Application Collision Avoidance seems to be achieved by > placing the DNS queries in the ENUM_ROOT_DOMAIN; does this mean > that we CANNOT place NAPTRs for other application types (e.g > URN resolution) in zones within this space (i.e. all NATPRs under > ENUM_ROOT_DOMAIN *MUST* be ENUM rules)? You can place NAPTRs for other application types in those zones. You just have to make sure that one applications rules can't be confused with another applications rules. This can be achieved four ways: 1) flags that are specific to an application and unknown to others, thus causing the other application to drop these rules on the floor since it doesn't understand its flags. Since ENUM uses the 'u' flag this wouldn't work for ENUM and URI Resolution. 2) Services and/or protocols that are also unique to the application. I discourage this because there is a good history of protocols and services being used outside our zone of control. 3) Matching rules that are specific to a namespace. By anchoring the match with the entire Key you can ensure that nothing else BUT that application can use that record. I always do this in my URI Resolution examples so that its clear what's being matched. 4) subdelegate to application specific zones. I.e. if you wanted to mix URI Resolution stuff inside e164.arpa I would delegate out of the 4.3.2.1.5.4.3.2.0.4.9.4.e164.arpa. with a uri-res zone. I.e.: uri-res.4.3.2.1.5.4.3.2.0.4.9.4.e164.arpa. and then simply make your rewrite rules talk about that domain instead of its parent. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 10:48:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24623 for ; Tue, 19 Feb 2002 10:48:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13859 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 10:48:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12351; Tue, 19 Feb 2002 10:29:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12320 for ; Tue, 19 Feb 2002 10:29:22 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23970 for ; Tue, 19 Feb 2002 10:29:18 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id HAA01290; Tue, 19 Feb 2002 07:28:43 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id <17L7PM1H>; Tue, 19 Feb 2002 07:28:43 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B014B0FCF@opwinex01.corp.illuminet.com> From: Kevin McCandless To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "'enum@ietf.org'" Subject: RE: [Enum] SIpping-e164 comments Date: Tue, 19 Feb 2002 07:28:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA12321 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit comments in line -----Original Message----- From: Patrik F�ltstr�m [mailto:paf@cisco.com] Sent: Saturday, February 16, 2002 2:14 AM To: Kevin McCandless; 'enum@ietf.org' Subject: Re: [Enum] SIpping-e164 comments --On 2002-02-15 11.33 -0800 Kevin McCandless wrote: > 4.4 Provisioning multiple NAPTR records ENUM records are not designed to > be updated in real time, > and therefore ENUM is not a good mechanism for managing particular > devices. .The idea behind this was really about "real time" updates because of the .caching mechanism in DNS. I didn't want to bring in a tutorial of DNS in .this document ;-) > Comment: This makes an assumption oh how ENUM will be > deployed. There is no reason that ENUM > could not be updated by a user in real time and the zone files updated > more frequency then the usual 24 hours. .It all depends on what you mean by Real Time. My definition is that if a .user at time N updates his records, at time N+1 (seconds) a client .somewhere should be guaranteed to have the new data. .That can never happen with DNS. .Nothing in DNS says the update should be "usual 24 hours". I have never .heard anything like that. Where have you got that information from? (I am .just curious.) It is caching that I am refering to here for the 24 hour updates. This can be greatly reduced as I mentioned previously. > There has been discussion of zone file updates as often as every fifteen > minutes. Lets leave the provisioning of NAPTR > records to the market place to decide how real time the records can be. .It is important to in some way mention that instant update (or some other .word) will _not_ be possible because of how DNS works. .Exactly how often is up to the DNS, and maybe new inventions in DNS. If you .use dns-notify then the authoritative servers are up to date. If you use .short TTL, then the records themselves will be updated often. .But, the time can not be zero. The time may never reach zero but the ENUM is no longer static and can be updated in a timely manner and viewable for the universe. Now, what the acceptable delay time is is an issue for the market place and not for this forum or draft. That was my point. .I appreciate suggestions on new wording. > 5. Processing ENUM records > Ideally, the recommendations above for authoring NAPTR records will be > followed to the letter; each NAPTR > record set will contain a SIP URI (and if possible nothing else). > Comment: Once again we are making the assumption for the market place. > ENUM is not just for SIP. > ENUM can be a DNS directory service. It could easily contain, in the > correct format, all of the usual contact information > that is listed on a business card. .I agree completely. I am glad we agree on somethings ;-) Kevin paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 11:17:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25860 for ; Tue, 19 Feb 2002 11:17:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15798 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 11:17:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14322; Tue, 19 Feb 2002 10:57:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14294 for ; Tue, 19 Feb 2002 10:57:50 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25061 for ; Tue, 19 Feb 2002 10:57:48 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id HAA03512; Tue, 19 Feb 2002 07:56:47 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id <17L7PMP5>; Tue, 19 Feb 2002 07:56:47 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B014B0FD0@opwinex01.corp.illuminet.com> From: Kevin McCandless To: "'Dave Crocker'" , Richard Shockey Cc: "'enum@ietf.org'" Subject: RE: [Enum] SIpping-e164 comments Date: Tue, 19 Feb 2002 07:56:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org You all missed the point and instead nit picked the words. ENUM is a directory. It can contain SIP URIs as well as my cell number or fax number. ENUM is not just for call setup. You can perform an ENUM query with your browser and get all the information that is normally contained on a business card. We get concerned when the submitted drafts and emails make market assumptions and do not stick to technical arguments. Kevin........ -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Sunday, February 17, 2002 11:20 AM To: Richard Shockey Cc: Kevin McCandless; 'enum@ietf.org' Subject: Re: [Enum] SIpping-e164 comments At 11:16 AM 2/17/2002 -0500, Richard Shockey wrote: >I think the DNS community would prefer it referred to as a database >service and not as a directory service ..that is part of the problem the >DNS now faces. Directory has all sorts of specific meanings associated with it. Indeed, the word 'directory' needs to be banned from all discussions involving the DNS, except when saying what the DNS is NOT. Database is a relatively generic and safe term. However if one seeks ideal terminology, it probably is a good idea also to shy away from the word database, for fear of invoking a range of generalities that do not apply, such as fast update and the caching problem already noted. Lookup or Mapping are the two words that are most often used to clarify what the DNS actual is. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 11:49:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26943 for ; Tue, 19 Feb 2002 11:49:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17887 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 11:49:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17444; Tue, 19 Feb 2002 11:40:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17413 for ; Tue, 19 Feb 2002 11:40:11 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26636 for ; Tue, 19 Feb 2002 11:40:09 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1JJd3166159; Tue, 19 Feb 2002 11:39:03 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202191939.g1JJd3166159@nic-naa.net> To: Kevin McCandless cc: "'Dave Crocker'" , Richard Shockey , "'enum@ietf.org'" , brunner@nic-naa.net Subject: Re: [Enum] SIpping-e164 comments In-Reply-To: Your message of "Tue, 19 Feb 2002 07:56:37 PST." <1C1EEC765F843E44996971A80682118B014B0FD0@opwinex01.corp.illuminet.com> Date: Tue, 19 Feb 2002 11:39:03 -0800 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > ENUM is a directory. In the testbed I used in November the components were: o one or more instances of bind o one or more instances of a SIP Redirect server (plug for Vovida) o one or more instances of a SIP UA (plug for Vovida) o one Pingtel handset o some address spaces (216.220, 159,226, 208.143) o some sequences of digits Where was the directory? What mechanism(s) in combination manifest "directory"? I'm plumb puzzled. ENOCLUE. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 12:03:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27652 for ; Tue, 19 Feb 2002 12:03:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20445 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 12:03:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18330; Tue, 19 Feb 2002 11:55:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18295 for ; Tue, 19 Feb 2002 11:55:08 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27155 for ; Tue, 19 Feb 2002 11:55:05 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA04223; Tue, 19 Feb 2002 17:54:58 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA28992; Tue, 19 Feb 2002 17:54:51 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id <1JWYCKAV>; Tue, 19 Feb 2002 17:54:57 +0100 Message-ID: From: Brandner Rudolf To: "'Michael Mealling'" Cc: enum@ietf.org, Conroy Lawrence Date: Tue, 19 Feb 2002 17:54:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA18296 Subject: [Enum] AW: DDDS, DNS clarification needed? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Many thanks for the clarification. Rudi > -----Urspr�ngliche Nachricht----- > Von: Michael Mealling [mailto:michael@neonym.net] > Gesendet: Dienstag, 19. Februar 2002 15:16 > An: Brandner Rudolf > Cc: enum@ietf.org; 'michael@research.netsol.com'; Conroy Lawrence > Betreff: Re: DDDS, DNS clarification needed? -----[original message deleted]----- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 12:08:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27790 for ; Tue, 19 Feb 2002 12:08:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20744 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 12:08:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18744; Tue, 19 Feb 2002 11:59:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18706 for ; Tue, 19 Feb 2002 11:59:13 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27469 for ; Tue, 19 Feb 2002 11:59:10 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1JGstI2029856; Tue, 19 Feb 2002 11:54:56 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1JGspgZ029855; Tue, 19 Feb 2002 11:54:51 -0500 (EST) Date: Tue, 19 Feb 2002 11:54:51 -0500 From: Michael Mealling To: Brandner Rudolf Cc: "'Michael Mealling'" , enum@ietf.org, Conroy Lawrence Message-ID: <20020219115451.W26811@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.3.22.1i Content-Transfer-Encoding: 8bit Subject: [Enum] Re: DDDS, DNS clarification needed? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit On Tue, Feb 19, 2002 at 05:54:43PM +0100, Brandner Rudolf wrote: > Many thanks for the clarification. Anytime. I've been collecting recent questions like this into an FAQ I'll be putting up latter this week. I also apologize for not being involved in the recent discussion. I fell off of the ENUM list and wasn't aware of it. -MM > > -----Urspr�ngliche Nachricht----- > > Von: Michael Mealling [mailto:michael@neonym.net] > > Gesendet: Dienstag, 19. Februar 2002 15:16 > > An: Brandner Rudolf > > Cc: enum@ietf.org; 'michael@research.netsol.com'; Conroy Lawrence > > Betreff: Re: DDDS, DNS clarification needed? > -----[original message deleted]----- -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 12:10:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27860 for ; Tue, 19 Feb 2002 12:10:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20948 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 12:10:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20085; Tue, 19 Feb 2002 12:01:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20047 for ; Tue, 19 Feb 2002 12:01:42 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27579 for ; Tue, 19 Feb 2002 12:01:39 -0500 (EST) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA05778; Tue, 19 Feb 2002 09:01:35 -0800 Message-Id: <5.1.0.14.2.20020219085810.020a7140@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Feb 2002 09:01:18 -0800 To: Kevin McCandless From: Dave Crocker Subject: RE: [Enum] SIpping-e164 comments Cc: Richard Shockey , "'enum@ietf.org'" In-Reply-To: <1C1EEC765F843E44996971A80682118B014B0FD0@opwinex01.corp.il luminet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 07:56 AM 2/19/2002 -0800, Kevin McCandless wrote: >You all missed the point and instead nit picked the words. On the contrary, the point was to pay attention to long-standing and pervasive usage in the real world. That pervasive usage has constantly shown a use of the word directory to refer to a broader set of functions than is present in the DNS. Most notably, the term is used to imply that a generic searching function is present. The distinction between searching and mapping, as done by the DNS, is fundamental. Confusing them prevents meaning dialogue about the DNS. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 13:37:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00801 for ; Tue, 19 Feb 2002 13:37:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26123 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 13:37:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25285; Tue, 19 Feb 2002 13:28:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25253 for ; Tue, 19 Feb 2002 13:28:46 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00410 for ; Tue, 19 Feb 2002 13:28:44 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1JIO3I2000390; Tue, 19 Feb 2002 13:24:03 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1JIO1Tj000389; Tue, 19 Feb 2002 13:24:01 -0500 (EST) Date: Tue, 19 Feb 2002 13:24:01 -0500 From: Michael Mealling To: urn-ietf@lists.netsol.com Cc: enum@ietf.org Message-ID: <20020219132401.J26811@bailey.dscga.com> Reply-To: Michael Mealling Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Subject: [Enum] updated DDDS drafts.... Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi all, You should see a new set of DDDS updates come by soon. The significant changes were due to IESG comments concerning a screw up in discussing the Preference and Priority fields. Apparently one of the documents discussed the Priority field in terms of weighted random selection in one section which is in exact opposition to the stated purpose of signifying preference in the other documents. This apparently tripped up one document author already. There were some other subsequence clarifications brought on by comments from the ENUM group (thanks guys!). I also changed the use of the term 'URL' to 'URI' where appropriate. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 19 15:49:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05040 for ; Tue, 19 Feb 2002 15:49:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02139 for enum-archive@odin.ietf.org; Tue, 19 Feb 2002 15:49:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01826; Tue, 19 Feb 2002 15:40:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01632 for ; Tue, 19 Feb 2002 15:37:18 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04684 for ; Tue, 19 Feb 2002 15:37:15 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1JKWaI2000887; Tue, 19 Feb 2002 15:32:37 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1JKWa5l000886; Tue, 19 Feb 2002 15:32:36 -0500 (EST) Date: Tue, 19 Feb 2002 15:32:36 -0500 From: Michael Mealling To: urn-ietf@lists.netsol.com, enum@ietf.org Message-ID: <20020219153236.P26811@bailey.dscga.com> Reply-To: Michael Mealling Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Subject: [Enum] frequently asked DDDS questions? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi everyone, I'm in the process of collecting questions for a DDDS FAQ. If you've found one or there some particular part of the DDDS you keep tripping up on I'd appreciate a short note letting me know what it is and what the answer is so I can put it in the list. You can see the beginnings at http://uri.net/ddds-faq.html. Thanks! -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 04:11:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25518 for ; Wed, 20 Feb 2002 04:11:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA11699 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 04:11:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11182; Wed, 20 Feb 2002 04:01:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11151 for ; Wed, 20 Feb 2002 04:01:20 -0500 (EST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25353 for ; Wed, 20 Feb 2002 04:01:17 -0500 (EST) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id g1K914p27921; Wed, 20 Feb 2002 09:01:09 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.35 #1) id 16dSbY-0002fS-00; Wed, 20 Feb 2002 09:00:00 +0000 Date: Wed, 20 Feb 2002 09:00:00 +0000 From: "Clive D.W. Feather" To: Lawrence Conroy Cc: Rudolf Brandner , enum@ietf.org, "'michael@research.netsol.com'" Subject: Re: [Enum] DDDS, DNS clarification needed? Message-ID: <20020220085959.GB8110@finch-staff-1.demon.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Lawrence Conroy said: > Question - Should the process of converting a key to DNS-suitable > form append a "well known constant" domain (e.g. ENUM_ROOT_DOMAIN), > rather than "hard-wiring" the domain? > The value of this constant is ".e164.arpa.", of course, and it *is* > a generalisation, but this may be useful in the future. I think this would be useful. Apart from anything else, it means that you can set up testbeds simply by changing the value of ENUM_ROOT_DOMAIN. If software expected to do this, the value would be configurable rather than hardwired, with obvious benefits. -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | NOTE: fax number change _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 05:16:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26322 for ; Wed, 20 Feb 2002 05:16:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA14831 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 05:16:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14324; Wed, 20 Feb 2002 05:03:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14295 for ; Wed, 20 Feb 2002 05:03:37 -0500 (EST) Received: from mail1.itu.ch (mail1.itu.ch [156.106.192.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26192 for ; Wed, 20 Feb 2002 05:03:33 -0500 (EST) Received: by mail1.itu.ch with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 11:03:05 +0100 Message-ID: <49ED700A32CFD511B72900508B959DFEB6E82E@mailsrv4.itu.ch> From: "Shaw, Robert" To: "'Clive D.W. Feather'" , Lawrence Conroy Cc: Rudolf Brandner , enum@ietf.org, "'michael@research.netsol.com'" Subject: RE: [Enum] DDDS, DNS clarification needed? Date: Wed, 20 Feb 2002 10:48:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > Question - Should the process of converting a key to DNS-suitable > > form append a "well known constant" domain (e.g. ENUM_ROOT_DOMAIN), > > rather than "hard-wiring" the domain? > > The value of this constant is ".e164.arpa.", of course, and it *is* > > a generalisation, but this may be useful in the future. > > I think this would be useful. Apart from anything else, it > means that you can set up testbeds simply by changing the value of > ENUM_ROOT_DOMAIN. If software expected to do this, the value would > be configurable rather than hardwired, with obvious benefits. This is prudent. While there are interim procedures to use e164.arpa (www.ripe.net/enum/) and strongly held views that this zone is the most appropriate there are equally strongly held views by some ITU Member States that without wishing to impede testing, there is a need for further review and discussion of the objective technical, operational and administrative criteria for the use of this zone. These discussions are still going on in ITU-T SG2. As an example, from a technical or operational perspective, such a list of criteria might be found in Annex F of the document at http://www.itu.int/itudoc/itu-t/workshop/enum/004.html. Bob -- Robert Shaw ITU Internet Strategy and Policy Advisor International Telecommunication Union Place des Nations, 1211 Geneva, Switzerland _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 05:44:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26562 for ; Wed, 20 Feb 2002 05:44:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA15980 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 05:44:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15729; Wed, 20 Feb 2002 05:34:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15700 for ; Wed, 20 Feb 2002 05:34:08 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26443 for ; Wed, 20 Feb 2002 05:34:04 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.224]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g1KAXWtR019190; Wed, 20 Feb 2002 11:33:35 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Feb 2002 11:20:01 +0100 Message-ID: From: "Stastny, Richard" To: "'Clive D.W. Feather'" , Lawrence Conroy Cc: enum@ietf.org Subject: RE: [Enum] DDDS, DNS clarification needed? Date: Wed, 20 Feb 2002 11:19:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I don not fully understand this discussion. Considering the Zillions of parameters already existing in operation systems and applications, I do not see the problem in including the ENUM Root Domain in the Application. Or the other way round, if I had to write an ENUM Add-on to Outlook, Netmeeting or Messenger, the first thing I would implement is a parameter for the ENUM Root Domain (also considering that the discussion is still not settled discussion between IAB and ITU), and second I would implement additional optional parameters for other root domains: e.g. if an number is entered with +, I would go to ENUM Root, with 000 also, any number without 0 or + to a private root, etc. I would expect to be able to enter digits on my office PC in the same way I use my PBX. regards Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com > -----Original Message----- > From: Clive D.W. Feather [mailto:clive@demon.net] > Sent: Wednesday, February 20, 2002 10:00 AM > To: Lawrence Conroy > Cc: Rudolf Brandner; enum@ietf.org; 'michael@research.netsol.com' > Subject: Re: [Enum] DDDS, DNS clarification needed? > > > Lawrence Conroy said: > > Question - Should the process of converting a key to DNS-suitable > > form append a "well known constant" domain (e.g. ENUM_ROOT_DOMAIN), > > rather than "hard-wiring" the domain? > > The value of this constant is ".e164.arpa.", of course, and it *is* > > a generalisation, but this may be useful in the future. > > I think this would be useful. Apart from anything else, it > means that you > can set up testbeds simply by changing the value of > ENUM_ROOT_DOMAIN. If > software expected to do this, the value would be configurable > rather than > hardwired, with obvious benefits. > > -- > Clive D.W. Feather | Work: | Tel: +44 > 20 8371 1138 > Internet Expert | Home: | Fax: +44 > 870 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: > +44 7973 377646 > Thus plc | | NOTE: fax > number change > > _______________________________________________ > 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 daemon@optimus.ietf.org Wed Feb 20 06:31:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27096 for ; Wed, 20 Feb 2002 06:31:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA18204 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 06:31:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17521; Wed, 20 Feb 2002 06:21:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17494 for ; Wed, 20 Feb 2002 06:21:55 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26903 for ; Wed, 20 Feb 2002 06:21:52 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062625; Wed, 20 Feb 2002 11:21:39 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: References: Date: Wed, 20 Feb 2002 11:24:07 +0000 To: "Stastny, Richard" , "'Clive D.W. Feather'" From: Lawrence Conroy Subject: RE: [Enum] DDDS, DNS clarification needed? Cc: enum@ietf.org, Robert.Shaw@itu.int Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:19 am +0100 20/2/02, Stastny, Richard wrote: >I don not fully understand this discussion. Considering the Zillions of >parameters already existing in operation systems and applications, I do not >see the problem in including the ENUM Root Domain in the Application. Or the >other way round, if I had to write an ENUM Add-on to Outlook, Netmeeting or >Messenger, the first thing I would implement is a parameter for the ENUM >Root Domain (also considering that the discussion is still not settled >discussion between IAB and ITU), and second I would implement additional >optional parameters for other root domains: e.g. if an number is entered >with +, I would go to ENUM Root, with 000 also, any number without 0 or + to >a private root, etc. > >I would expect to be able to enter digits on my office PC in the same way I >use my PBX. > >And before that Clive wrote: > >(In response to my earlier posting): > > Lawrence Conroy said: >> > Question - Should the process of converting a key to DNS-suitable >> > form append a "well known constant" domain (e.g. ENUM_ROOT_DOMAIN), >> > rather than "hard-wiring" the domain? >> > The value of this constant is ".e164.arpa.", of course, and it *is* >> > a generalisation, but this may be useful in the future. Clive said: > > >> I think this would be useful. Apart from anything else, it >> means that you >> can set up testbeds simply by changing the value of >> ENUM_ROOT_DOMAIN. If >> software expected to do this, the value would be configurable >> rather than > > hardwired, with obvious benefits. >> To which I reply: Hi Folks, Sorry for any confusion this causes. IMHO, it's really no big deal. The aim of using an ENUM_ROOT_DOMAIN is only to avoid having to put ".e164.arpa" throughout the documents, *and* ... to indicate the Application Clash Avoidance mechanism required of DDDS applications - basically, we put all ENUM-specific NAPTRs under the ENUM_ROOT_DOMAIN, and there are no NAPTRS that are specific to other DDDS applications within this domain space, so we avoid a clash. Confused? - so am I, but it's a start. Now, this is pretty much standards document "syntactic sugar". If there is a "private" system that operates like ENUM, then it should *mostly* be a case of re-defining the root domain under which this other system operates - it will NOT use "e164.arpa", as that is reserved for the ("public") ENUM system. When Richard's add-on to Outlook gets a number without a leading + it can use this new non-ENUM application and operate as expected. If there's a + (or a 000, converted to +), then it fires up the ENUM application and all is fine. BTW: Yes, I am aware of the current discussions in SG2 on whether or not ".e164.arpa" is or is not appropriate. To be honest, I'm not driven by religious fervor on this topic, as long as it's independent I don't see why it needs a sub-working group to discuss it. (That's why I'm an Engineer and don't get the big bucks, I guess :) Also, I've looked at the meeting documents Bob mentioned, and consider that Appendix F is an excellent document - congratulations to the author(s). Best Regards, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 08:20:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29695 for ; Wed, 20 Feb 2002 08:20:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22465 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 08:20:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22018; Wed, 20 Feb 2002 08:08:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21989 for ; Wed, 20 Feb 2002 08:08:45 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29354 for ; Wed, 20 Feb 2002 08:08:41 -0500 (EST) Received: from dhcp-64-103-48-146.cisco.com (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA27849; Wed, 20 Feb 2002 14:00:52 +0100 (MET) Date: Wed, 20 Feb 2002 13:52:45 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Stastny, Richard" , "'Clive D.W. Feather'" , Lawrence Conroy cc: enum@ietf.org Subject: RE: [Enum] DDDS, DNS clarification needed? Message-ID: <1015532.1014213165@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-20 11.19 +0100 "Stastny, Richard" wrote: > I don not fully understand this discussion. Considering the Zillions of > parameters already existing in operation systems and applications, I do > not see the problem in including the ENUM Root Domain in the Application. > Or the other way round, if I had to write an ENUM Add-on to Outlook, > Netmeeting or Messenger, the first thing I would implement is a parameter > for the ENUM Root Domain (also considering that the discussion is still > not settled discussion between IAB and ITU), and second I would implement > additional optional parameters for other root domains: e.g. if an number > is entered with +, I would go to ENUM Root, with 000 also, any number > without 0 or + to a private root, etc. This is not an implementation issue. You have to differ between: 1 How you handle the global E.164 space 2 How you handle private dialing plans 3 How you implement things in your software Three very different things. Let's take them one at a time, for the last time: 1. The ENUM work in the IETF had as a task to find out how to use DNS to find URL's when one _only_ knew the E.164 number. No other knowledge is available. Let's say that I can choose between a.com and b.com as the domain, and I use b.com. If I give you my E.164 number (only), how are you to know that it is b.com you should use? I.e. the issues are exactly the same as with a single root in DNS as a whole. See draft-iab-itu-enum-notes-00.txt 2. If you and everyone which use a private dialing plan you can agree on using a different domain for storage of DNS data. That is according to the definitions we use in this wg though _NOT_ ENUM. This builds onto the fact that you need to have some extra knowledge part from the E.164 number, the domain you will use when looking up the NAPTR. I do though know several cases (for example internally in a company) where this is extremely useful. 3. Given that software probably should be able to handle both (1) and (2) it of course probably should be implemented in as dynamic way as possible. Did this make things more clear? paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 08:36:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00108 for ; Wed, 20 Feb 2002 08:36:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23676 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 08:36:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22773; Wed, 20 Feb 2002 08:26:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22742 for ; Wed, 20 Feb 2002 08:26:33 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29846 for ; Wed, 20 Feb 2002 08:26:29 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA27831; Wed, 20 Feb 2002 08:25:26 -0500 (EST) Received: from fractal.verisign.com (10.145.9.138 [10.145.9.138]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15YHSHPJ; Wed, 20 Feb 2002 08:26:10 -0500 Message-Id: <5.1.0.14.2.20020220081313.01e54278@216.168.234.202> X-Sender: trutkowski@216.168.234.202 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 08:25:03 -0500 To: Lawrence Conroy , "Stastny, Richard" , "'Clive D.W. Feather'" From: Tony Rutkowski Subject: RE: [Enum] DDDS, DNS clarification needed? Cc: enum@ietf.org, Robert.Shaw@itu.int In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 06:24 AM 2/20/2002, Lawrence Conroy wrote: >If there is a "private" system that operates like ENUM, then >it should *mostly* be a case of re-defining the root domain under >which this other system operates - it will NOT use "e164.arpa", as >that is reserved for the ("public") ENUM system. The Internet and its services (including DNS) under current international (and most national) law are "private." The one and only authoritative "public" E.164 syntax is that of the ITU and its Member States, and the mappings are provided via SS7 infrastructure. That authority is not going to be ceded to an advisory committee of the Internet Society (i.e., the legal status of the IAB). This is the first well-understood rule. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 09:34:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01703 for ; Wed, 20 Feb 2002 09:34:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26661 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 09:34:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25773; Wed, 20 Feb 2002 09:24:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25740 for ; Wed, 20 Feb 2002 09:24:27 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01384 for ; Wed, 20 Feb 2002 09:24:22 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1KEMx169215; Wed, 20 Feb 2002 06:22:59 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202201422.g1KEMx169215@nic-naa.net> To: Tony Rutkowski cc: Lawrence Conroy , "Stastny, Richard" , "'Clive D.W. Feather'" , enum@ietf.org, Robert.Shaw@itu.int, brunner@nic-naa.net Subject: Re: [Enum] DDDS, DNS clarification needed? In-Reply-To: Your message of "Wed, 20 Feb 2002 08:25:03 EST." <5.1.0.14.2.20020220081313.01e54278@216.168.234.202> Date: Wed, 20 Feb 2002 09:22:59 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Tony, In Federal Indian Law every question begins with a jurisdictional analysis. I mention FIL because it is something I know a (very) little bit about, so there is a (small) possibility I'll understand some of your reply. > The Internet and its services (including DNS) under current > international (and most national) law are "private." What is your jurisdictional framework? Can you cite an exception to the "most national" observation? Can you cite an instance of this general characteristic? I wish this list had a meta-enum@where.ever for non-technical discussions. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 10:11:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03016 for ; Wed, 20 Feb 2002 10:11:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28706 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 10:11:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28196; Wed, 20 Feb 2002 10:02:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28166 for ; Wed, 20 Feb 2002 10:02:54 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02722 for ; Wed, 20 Feb 2002 10:02:49 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA02235; Wed, 20 Feb 2002 09:57:43 -0500 (EST) Received: from fractal.verisign.com (10.145.9.138 [10.145.9.138]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15YHSJVX; Wed, 20 Feb 2002 09:58:27 -0500 Message-Id: <5.1.0.14.2.20020220093308.01e66a20@216.168.234.202> X-Sender: trutkowski@216.168.234.202 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 09:57:20 -0500 To: Eric Brunner-Williams in Portland Maine From: Tony Rutkowski Subject: Re: [Enum] DDDS, DNS clarification needed? Cc: Lawrence Conroy , "Stastny, Richard" , "'Clive D.W. Feather'" , enum@ietf.org, Robert.Shaw@itu.int, brunner@nic-naa.net In-Reply-To: <200202201422.g1KEMx169215@nic-naa.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >What is your jurisdictional framework? Can you cite an exception to the >"most national" observation? Can you cite an instance of this general >characteristic? > >I wish this list had a meta-enum@where.ever for non-technical discussions. Hi Eric, This is not a useful forum - although by virtue of getting into administrative matters, including privacy, etc, - substantial non-technical discussions are implicated. I'm putting together an extensive ID on this that will be presented next month at a Federal Communications Bar gathering, so perhaps the detail can be deferred. However, in a nutshell, the term "public" as it applies broadly to telecommunication services has an explicit connotation going back 150 years in treaty instruments and domestic law. The world of networks and services over that time has been bifurcated fundamentally into public and private. This includes multiple treaties in force of both the International Telecommunication Union and the World Trade Organization. It's also organically embedded in many national statutory and regulatory provisions. Until the late 80s, it was unlawful in most jurisdictions to use private leased lines to construct any networks that provided services to the public. The networks were restricted to intra-organization closed user groups only. The Internet in particular was regarded as a threat. The devised created was to denominate all Internet networks and services as "private" among closed user groups not offering services to the public. That remains the basic paradigm today - although it is getting nibbled around the edges as those who inhabit the cybertelecom list know. There are also related bifurcations between "basic" and "enhanced" or "value-added" that reinforce the public-private dichotomy. If you want "authoritative public services," it's a very different legal and policy ballgame that's subject to a great deal of global, regional, national, state, and local law and regulatory regimes. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 10:16:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03212 for ; Wed, 20 Feb 2002 10:16:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29036 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 10:16:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28511; Wed, 20 Feb 2002 10:08:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28482 for ; Wed, 20 Feb 2002 10:08:19 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02938 for ; Wed, 20 Feb 2002 10:08:14 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.224]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g1KF8EtQ013925; Wed, 20 Feb 2002 16:08:14 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Feb 2002 15:52:30 +0100 Message-ID: From: "Stastny, Richard" To: "'Tony Rutkowski'" Cc: enum@ietf.org Subject: RE: [Enum] DDDS, DNS clarification needed? Date: Wed, 20 Feb 2002 15:52:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Please, I did not intend to start a discussion on private or public regarding the Internet. I just wanted to state, that users of _ENUM_ and _ENUM LIKE_ services, since they will use phone numbers as input to establish comunication, may like to use the same conventions the are already used to with existing phone systems, so I used the _analogy_ of public and private DIALLING plans. And to end the discussion on the political correct ENUM root, maybe IAB and ITU-T may set up a server, where the currently valid root for RFC2916 ENUM is stored and all clients have to look it up before adding it to the number string (e.g. like the bubble coming up for the Windows update: there is an ENUM Root update for you ;-) regards Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com] > Sent: Wednesday, February 20, 2002 2:25 PM > To: Lawrence Conroy; Stastny, Richard; 'Clive D.W. Feather' > Cc: enum@ietf.org; Robert.Shaw@itu.int > Subject: RE: [Enum] DDDS, DNS clarification needed? > > > At 06:24 AM 2/20/2002, Lawrence Conroy wrote: > >If there is a "private" system that operates like ENUM, then > >it should *mostly* be a case of re-defining the root domain under > >which this other system operates - it will NOT use "e164.arpa", as > >that is reserved for the ("public") ENUM system. > > The Internet and its services (including DNS) under current > international (and most national) law are "private." > > The one and only authoritative "public" E.164 syntax is that > of the ITU and its Member States, and the mappings are > provided via SS7 infrastructure. > > That authority is not going to be ceded to an advisory > committee of the Internet Society (i.e., the legal status > of the IAB). > > This is the first well-understood rule. > > --tony > > > _______________________________________________ > 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 daemon@optimus.ietf.org Wed Feb 20 10:38:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04051 for ; Wed, 20 Feb 2002 10:38:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00410 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 10:38:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29617; Wed, 20 Feb 2002 10:29:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29593 for ; Wed, 20 Feb 2002 10:29:33 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03615 for ; Wed, 20 Feb 2002 10:29:30 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16dYdY-000EnC-00; Wed, 20 Feb 2002 07:26:28 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Shaw Bob Cc: "Clive D.W. Feather" , Lawrence Conroy , Rudolf Brandner , enum@ietf.org, michael@research.netsol.com Subject: RE: [Enum] DDDS, DNS clarification needed? References: <49ED700A32CFD511B72900508B959DFEB6E82E@mailsrv4.itu.ch> Message-Id: Date: Wed, 20 Feb 2002 07:26:28 -0800 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit the idea of different e164.foos is great. it should be used to map the different global numbering plans, you know, the ones where north america is +42, +666, etc. for the nonce, we will use e164.arpa to map the current prosaic global numbering plan, where north america is +1. btw, when will the itu be publishing these alternate numbering plans? randy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 11:48:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06103 for ; Wed, 20 Feb 2002 11:48:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04435 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 11:48:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04001; Wed, 20 Feb 2002 11:39:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03969 for ; Wed, 20 Feb 2002 11:39:36 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05878 for ; Wed, 20 Feb 2002 11:39:32 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Wed, 20 Feb 2002 08:38:27 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 20 Feb 2002 08:39:05 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Feb 2002 08:38:26 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Feb 2002 08:38:24 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 20 Feb 2002 08:36:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message Subject: Implementer's dilemma (was RE: [Enum] DDDS, DNS clarification needed?) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 20 Feb 2002 08:36:20 -0800 Message-ID: Thread-Topic: Implementer's dilemma (was RE: [Enum] DDDS, DNS clarification needed?) thread-index: AcG5+0p8+QvZDIrcS3al2VygTsT4ZAAL/b6Q From: "Christian Huitema" To: "Stastny, Richard" , "Clive D.W. Feather" , "Lawrence Conroy" Cc: X-OriginalArrivalTime: 20 Feb 2002 16:36:21.0233 (UTC) FILETIME=[BA703E10:01C1BA2C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA03970 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit > I don not fully understand this discussion. Considering the Zillions of > parameters already existing in operation systems and applications, I do > not > see the problem in including the ENUM Root Domain in the Application. Or > the > other way round, if I had to write an ENUM Add-on to Outlook, Netmeeting > or > Messenger, the first thing I would implement is a parameter for the ENUM > Root Domain (also considering that the discussion is still not settled > discussion between IAB and ITU), and second I would implement additional > optional parameters for other root domains: e.g. if an number is entered > with +, I would go to ENUM Root, with 000 also, any number without 0 or + > to > a private root, etc. Alternately, whoever has to write such an interface to ENUM might just wait a little for the dust to settle? I believe that there are two issues to resolve before implementers feel comfortable with ENUM: 1) There is a usability issue to determine when a telephone number has to be resolved as an identifier (i.e. through ENUM) versus as a routing index (i.e. through the routing protocol proposed by the INTEL group): ring that device versus ring the owner of the device. 2) There is a cost benefit issue to determine whether paying the cost of an ENUM look-up (potentially a second or two) is worth the benefit (finding useful information). My personal conclusion is that ENUM look-up SHOULD NOT be performed "in real-time" during call set-up, since there is ambiguity about the meaning of entering a phone number in a call procedure and there is a large probability, at least in the initial phase, that the ENUM database will not hold any information for a specific number; real-time call redirection, if needed, can always be performed by the target of the call, or by the last switch. If I was to implement any support for ENUM, it would be in an "off-line" procedure e.g. an add-on to the management of the local address book. Now, if you think "off-line", it is very easy to look in multiple databases and let the user choose. -- Christian Huitema _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 12:11:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07103 for ; Wed, 20 Feb 2002 12:11:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA07280 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 12:11:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06648; Wed, 20 Feb 2002 12:02:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06617 for ; Wed, 20 Feb 2002 12:02:25 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06707 for ; Wed, 20 Feb 2002 12:02:21 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA10124; Wed, 20 Feb 2002 17:57:33 +0100 (MET) Date: Wed, 20 Feb 2002 17:51:02 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Christian Huitema , "Stastny, Richard" , "Clive D.W. Feather" , Lawrence Conroy cc: enum@ietf.org Subject: Re: Implementer's dilemma (was RE: [Enum] DDDS, DNS clarification needed?) Message-ID: <1728940.1014227462@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-20 08.36 -0800 Christian Huitema wrote: > 1) There is a usability issue to determine when a telephone number has > to be resolved as an identifier (i.e. through ENUM) versus as a routing > index (i.e. through the routing protocol proposed by the INTEL group): > ring that device versus ring the owner of the device. Clearification question: Do you mean IPTEL, and for example TRIP? paf, slightly confused, maybe ;-) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 12:12:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07202 for ; Wed, 20 Feb 2002 12:12:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA07439 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 12:12:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06788; Wed, 20 Feb 2002 12:04:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06757 for ; Wed, 20 Feb 2002 12:04:02 -0500 (EST) Received: from mail2.itu.ch (mail2.itu.ch [156.106.192.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06766 for ; Wed, 20 Feb 2002 12:03:58 -0500 (EST) Received: by mail2.itu.ch with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 18:03:28 +0100 Message-ID: <49ED700A32CFD511B72900508B959DFEB6E841@mailsrv4.itu.ch> From: "Shaw, Robert" To: "'Randy Bush'" Cc: enum@ietf.org Subject: RE: [Enum] DDDS, DNS clarification needed? Date: Wed, 20 Feb 2002 18:00:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > the idea of different e164.foos is great. it should be used > to map the different global numbering plans, you know, the ones where > north america is +42, +666, etc. for the nonce, we will use e164.arpa > to map the current prosaic global numbering plan, where north america > is +1. > > btw, when will the itu be publishing these alternate numbering plans? > Huh? Interesting leap of logic... Randy, the real world has this habit of defying one's instinctive or even one's strongly held engineering beliefs. A coordinated hierarchical symbol set (to use 2826 terminology) does not a priori require a single technical root. In the PSTN world, that's a simple fact and proof that one can have a coordinated hierarchical addressing system that is not dependent upon a single technical root. A disadvantage of this model is that it requires a much more complex level of coordination among various systems; made more difficult with telecoms liberalization and the growth in facilities-based carriers. I know that it's a difficult transition for some but the issues are deeper and go beyond technical elegance of pulling a symbol set from one central computer or switch somewhere. There are other factors such as real world geopolitics, national sovereignty over critical infrastructure, CI security issues, intercept, etc. If you make the mental leap that discussing where ENUM is rooted a priori implies a non-coordinated country code symbol space, then I'd have to say that I'd disagree with your assumption. Bob _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 12:14:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07292 for ; Wed, 20 Feb 2002 12:14:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA07662 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 12:14:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06964; Wed, 20 Feb 2002 12:06:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06933 for ; Wed, 20 Feb 2002 12:06:02 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06879 for ; Wed, 20 Feb 2002 12:05:57 -0500 (EST) Received: from [128.177.194.170] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E3B2D31914; Wed, 20 Feb 2002 09:05:28 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Wed, 20 Feb 2002 09:05:26 -0800 Subject: Re: [Enum] DDDS, DNS clarification needed? From: David Conrad To: Randy Bush , Shaw Bob Cc: "Clive D.W. Feather" , Lawrence Conroy , Rudolf Brandner , enum wg , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Amusing(?) hyperbole aside, the real question for people interested in actually implementing this stuff (as opposed to going to meetings and talking about it) isn't "when", but "where". It is all fine and dandy for the IESG/IAB folks to declare the telephone number mapping into the DNS is in "e164.arpa" (and redefine "arpa" to try to make it more palatable), however if the PTTs and telcos of the world (you remember, the folks who tend to have apartments in Geneva) don't play along, software implementations will almost certainly have to have append the domain string that the PTTs and telcos agree upon. It doesn't matter a whole lot to an ENUM client implementation if it looks up 3.0.0.6.1.8.3.0.5.6.1.e164.arpa or 3.0.0.6.1.8.3.0.5.6.1.tel.itu.int. It does matter if the conjunction is "and". Rgds, -drc On 2/20/02 7:26 AM, "Randy Bush" wrote: > the idea of different e164.foos is great. it should be used to map the > different global numbering plans, you know, the ones where north america > is +42, +666, etc. for the nonce, we will use e164.arpa to map the > current prosaic global numbering plan, where north america is +1. > > btw, when will the itu be publishing these alternate numbering plans? > > randy > > _______________________________________________ > 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 daemon@optimus.ietf.org Wed Feb 20 12:30:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09855 for ; Wed, 20 Feb 2002 12:30:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08949 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 12:30:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08100; Wed, 20 Feb 2002 12:22:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08069 for ; Wed, 20 Feb 2002 12:22:15 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07677 for ; Wed, 20 Feb 2002 12:22:10 -0500 (EST) Received: from [193.118.192.40] ([193.118.192.40] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062649; Wed, 20 Feb 2002 17:22:02 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: In-Reply-To: References: <49ED700A32CFD511B72900508B959DFEB6E82E@mailsrv4.itu.ch> Date: Wed, 20 Feb 2002 17:24:29 +0000 To: Randy Bush From: Lawrence Conroy Subject: RE: [Enum] DDDS, DNS clarification needed? Cc: Rudolf Brandner , enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 7:26 am -0800 20/2/02, Randy Bush wrote: >the idea of different e164.foos is great. it should be used to map the >different global numbering plans, you know, the ones where north america >is +42, +666, etc. for the nonce, we will use e164.arpa to map the >current prosaic global numbering plan, where north america is +1. > >btw, when will the itu be publishing these alternate numbering plans? > >randy > OK folks, mea culpa, mea maxima culpa. I hereby promise to remove all reference to ENUM_ROOT or ENUM_ROOT_DOMAIN from anything I write. As for the e164 root canal draft to which I assume this post relates, I note an error in the issue date; it should be Easter Monday, surely? These Americans are Soooo crazy. best regards, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 12:40:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10495 for ; Wed, 20 Feb 2002 12:40:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09748 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 12:40:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09087; Wed, 20 Feb 2002 12:31:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09058 for ; Wed, 20 Feb 2002 12:31:23 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09920 for ; Wed, 20 Feb 2002 12:31:18 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1KHInI2003841; Wed, 20 Feb 2002 12:18:50 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1KHIlts003840; Wed, 20 Feb 2002 12:18:47 -0500 (EST) Date: Wed, 20 Feb 2002 12:18:47 -0500 From: Michael Mealling To: "Shaw, Robert" Cc: "'Randy Bush'" , enum@ietf.org Subject: Re: [Enum] DDDS, DNS clarification needed? Message-ID: <20020220121847.R26811@bailey.dscga.com> Reply-To: Michael Mealling References: <49ED700A32CFD511B72900508B959DFEB6E841@mailsrv4.itu.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49ED700A32CFD511B72900508B959DFEB6E841@mailsrv4.itu.ch> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Wed, Feb 20, 2002 at 06:00:35PM +0100, Shaw, Robert wrote: > > the idea of different e164.foos is great. it should be used > > to map the different global numbering plans, you know, the ones where > > north america is +42, +666, etc. for the nonce, we will use e164.arpa > > to map the current prosaic global numbering plan, where north america > > is +1. > > > > btw, when will the itu be publishing these alternate numbering plans? > > > > Huh? Interesting leap of logic... > > Randy, the real world has this habit of defying one's > instinctive or even one's strongly held engineering > beliefs. > > A coordinated hierarchical symbol set (to use 2826 > terminology) does not a priori require a single > technical root. In the PSTN world, that's a simple > fact and proof that one can have a coordinated > hierarchical addressing system that is not dependent > upon a single technical root. > > A disadvantage of this model is that it requires a > much more complex level of coordination among various > systems; made more difficult with telecoms > liberalization and the growth in facilities-based > carriers. > > I know that it's a difficult transition for some but > the issues are deeper and go beyond technical > elegance of pulling a symbol set from one central > computer or switch somewhere. There are other factors such > as real world geopolitics, national sovereignty over critical > infrastructure, CI security issues, intercept, etc. > > If you make the mental leap that discussing where ENUM is > rooted a priori implies a non-coordinated country code symbol > space, then I'd have to say that I'd disagree with your > assumption. I think Randy's point is that if ENUM is rooted in multiple locations what is to keep one of those locations from ignoring the coordinated country code symbol space? In the telephony world setting up infrastructure to advertise that fact costs hundreds of millions of dollars and in many cases a blessing from the King. In the Internet it just takes one computer and an Internet connection... How do you keep that symbol space coordinated when the guy running one of those ENUM locations is a 12 year old kid who really doesn't care about helping that space stay coordinated? -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 13:21:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12718 for ; Wed, 20 Feb 2002 13:21:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11935 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 13:21:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11585; Wed, 20 Feb 2002 13:12:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11553 for ; Wed, 20 Feb 2002 13:12:05 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12467 for ; Wed, 20 Feb 2002 13:12:03 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Wed, 20 Feb 2002 10:10:56 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 20 Feb 2002 10:11:34 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Feb 2002 10:11:34 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Feb 2002 10:10:56 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 20 Feb 2002 10:08:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Implementer's dilemma (was RE: [Enum] DDDS, DNS clarificationneeded?) Date: Wed, 20 Feb 2002 10:08:52 -0800 Message-ID: Thread-Topic: Implementer's dilemma (was RE: [Enum] DDDS, DNS clarificationneeded?) thread-index: AcG6L1NoD4Mmyoe6Qha1iXP7pxncaQACpJVw From: "Christian Huitema" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Stastny, Richard" , "Clive D.W. Feather" , "Lawrence Conroy" Cc: X-OriginalArrivalTime: 20 Feb 2002 18:08:52.0688 (UTC) FILETIME=[A75D0D00:01C1BA39] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA11554 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit > > 1) There is a usability issue to determine when a telephone number has > > to be resolved as an identifier (i.e. through ENUM) versus as a routing > > index (i.e. through the routing protocol proposed by the INTEL group): > > ring that device versus ring the owner of the device. > > Clearification question: Do you mean IPTEL, and for example TRIP? Yes, I meant IPTEL. Somehow I confused "IP telephony" and "Internet Telephony." Sorry about that. -- Christian Huitema _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 14:09:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16422 for ; Wed, 20 Feb 2002 14:09:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA15273 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 14:09:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14547; Wed, 20 Feb 2002 14:01:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14507 for ; Wed, 20 Feb 2002 14:01:01 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16095 for ; Wed, 20 Feb 2002 14:00:58 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1KJ02J01401 for ; Wed, 20 Feb 2002 14:00:17 -0500 Message-Id: <5.1.0.14.2.20020220120147.0236bc38@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 14:01:53 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] ENUM WG Agenda Slots Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I'm beginning to compile an agenda for the WG meeting in MN and I'd like to start taking requests tomorrow after the ID editor cut off date. I'm assuming that several people have documents in the hopper that will be posted shortly. I want to emphasize now that we only want to discuss items that have been reviewed on the list and that we are not going to permit tutorial presentations etc. A request for a time slot is to focus WG attention on problems previously identified and that discussion in the meeting is oriented to reaching consensus etc. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 14:54:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18064 for ; Wed, 20 Feb 2002 14:54:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17311 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 14:54:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16941; Wed, 20 Feb 2002 14:45:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16915 for ; Wed, 20 Feb 2002 14:45:09 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17783 for ; Wed, 20 Feb 2002 14:45:05 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1KJao175271; Wed, 20 Feb 2002 11:36:50 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202201936.g1KJao175271@nic-naa.net> To: Tony Rutkowski cc: Eric Brunner-Williams in Portland Maine , Lawrence Conroy , "Stastny, Richard" , "'Clive D.W. Feather'" , enum@ietf.org, Robert.Shaw@itu.int, brunner@nic-naa.net Subject: Re: [Enum] DDDS, DNS clarification needed? In-Reply-To: Your message of "Wed, 20 Feb 2002 09:57:20 EST." <5.1.0.14.2.20020220093308.01e66a20@216.168.234.202> Date: Wed, 20 Feb 2002 14:36:50 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Tony, The response you provided wasn't ... responsive. Two houses, both alike in dignity, in the fair Verona(s) where you lay your scene. One with private law, one with public law, and both with dns or any like infrastructure you think applicable. You can respond off-list, and as briefly as two iso3166 values. Actually, I just need the private one, I've got a public one -- .cn. I still wish this list had a meta-foo outlet for non-technical discussions. I'm cluttering up other people's mailboxes as someone else may have one or more examples, and off-list reply is _fine_ by me. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 15:37:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19222 for ; Wed, 20 Feb 2002 15:37:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19783 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 15:37:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19071; Wed, 20 Feb 2002 15:28:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19039 for ; Wed, 20 Feb 2002 15:28:38 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18911 for ; Wed, 20 Feb 2002 15:28:33 -0500 (EST) Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA00473 for ; Wed, 20 Feb 2002 12:28:35 -0800 Message-Id: <5.1.0.14.2.20020220120521.03c41150@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 12:22:20 -0800 To: enum@ietf.org From: Dave Crocker Subject: RE: [Enum] DDDS, DNS clarification needed? In-Reply-To: <49ED700A32CFD511B72900508B959DFEB6E841@mailsrv4.itu.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >A coordinated hierarchical symbol set (to use 2826 >terminology) does not a priori require a single >technical root. In the PSTN world, that's a simple >fact and proof that one can have a coordinated >hierarchical addressing system that is not dependent >upon a single technical root. Folks, Discussions involving DNS and the concept of "root" have a regular tendency to confuse administrative control with instantiation of databases and machines. Each has a technical component, but involve very different issus. There is some chance that that confusion is happening in this thread, too. A hierarchy like the telephone numbering system does require a single point of control. That is a technical imperitive. Whether that point is a single person, a single organization, a contract jointly signed by folks running the next level down in the tree, a piece of software that instantiates some particular policy, or some other coherent mechanism, it is a single point of logical control. In other words, there are many ways to instantiate a single, logical control mechanism, and the choice involves an interesting range of trade-offs that are technical, political, etc. Operational optimizations that delegate and distribute logical subsets of the database, or permit synchronized replications of portions of the database, are entirely irrelevant to matters of administrative and logical control. These operational matters do not involve control. The debate that is being raised here involves two different control matters: 1. Venue for administrative control 2. Form of administrative control The enum mailing list is an IETF technical working group. It does not specify venue for control and, therefore, that question is entirely out of scope for this group. On the matter of form, the technical question is whether there are technical components to DNS sub-tree administration that would need changes to support a particular operational model. To date, there have been no proposals for such changes, and no indication that this kind of discussion will lead to such a proposal. In fact, these discussions tend to eschew technical content. Hence, this debate is a matter of philosophy rather than specification. Such a debate is notably unproductive. So we should all move the venue of the discussion to a bar BOF and leave the enum working to continue worrying about enum technical specifications. d/ ps. For this topic, there might be one activity that would be productive, and that is to produce a lexicon of terminology that bridges DNS and PSTN language, to permit consistent reference to these different issues. Ain't cultural diversity fun? ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 16:03:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20065 for ; Wed, 20 Feb 2002 16:03:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21427 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 16:03:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20744; Wed, 20 Feb 2002 15:54:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20714 for ; Wed, 20 Feb 2002 15:54:13 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19849 for ; Wed, 20 Feb 2002 15:54:09 -0500 (EST) Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA01334; Wed, 20 Feb 2002 12:52:44 -0800 Message-Id: <5.1.0.14.2.20020220124634.03594498@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 12:49:36 -0800 To: Tony Rutkowski From: Dave Crocker Subject: Re: [Enum] DDDS, DNS clarification needed? Cc: Eric Brunner-Williams in Portland Maine , Lawrence Conroy , "Stastny, Richard" , "'Clive D.W. Feather'" , enum@ietf.org, Robert.Shaw@itu.int, brunner@nic-naa.net In-Reply-To: <5.1.0.14.2.20020220093308.01e66a20@216.168.234.202> References: <200202201422.g1KEMx169215@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 09:57 AM 2/20/2002 -0500, Tony Rutkowski wrote: >However, in a nutshell, the term "public" as it applies >broadly to telecommunication services has an explicit >connotation going back 150 years in treaty instruments >and domestic law. Tony, Perhaps you have not noticed that this is not a law forum? The term public, when used in the IETF, is not being used as a legal term of art, no matter how much attorneys might try to force otherwise. So it is a wonderful thing that you know about such matters of legal history. No doubt many people would like to hear such recitations. However they are quite irrelevant to this technical working group, so such pedagogy belongs elsewhere, as you have often been told. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 16:54:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21541 for ; Wed, 20 Feb 2002 16:54:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA23395 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 16:54:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22952; Wed, 20 Feb 2002 16:46:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22920 for ; Wed, 20 Feb 2002 16:46:08 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21298 for ; Wed, 20 Feb 2002 16:46:03 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1KLdFJ06833; Wed, 20 Feb 2002 16:39:30 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id <1T7FVG68>; Wed, 20 Feb 2002 15:39:00 -0600 Message-ID: <23309E398D84D5119D0F00306E075139ECEC5C@dc02.npac.com> From: "Yu, James" To: "'Lawrence Conroy'" Cc: enum@ietf.org, paf@cisco.com Subject: RE: [Enum] Re. 2916bis Date: Wed, 20 Feb 2002 15:38:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA22921 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit For (iii), one good example is a non-geographical number (e.g., toll free number) that is mapped to a POTS number (geographical number). There may be a "need" to re-submit. It is possible to retrieve a tel URL with TN#B via ENUM on TN#A. It certainly is fine to do ENUM lookup on TN#B. But this process can go on if in the worst case a tel URL is the only URL retrieved via ENUM. The application should set a limit to such re-submissions. We need to be careful about putting tel URL in the ENUM NAPTR RRs. This is because a U.S. TN being mapped to a Russian TN may cause charging issue especially when that Russian TN is a PSTN TN (e.g., call must be terminated via gateway into the PSTN in Russia). The caller in the U.S. dials a U.S. TN and expects to pay a domestic long distance (or even local) rate for the call. But what if this TN is mapped to a Russian TN via ENUM in the IP domain? Must the caller pay an international call rate? The caller certainly will argue that he dialed a local/domestic TN. Someone may argue that the "called party" (e.g., ENUM registrant) should pay for the "call forwarding/delivery." But the problem is that the one that performs ENUM/DNS query may not have any relationship with the "called party;" therefore, it won't be easy to bill that "called party." So any valid TN can appear in the tel URL in the NAPTR RR, I see several possible ways of handling that particular tel URL (TN) if the TN will cause charging issue (a U.S. TN mapped to a Russian TN) - If the caller's phone did the ENUM query, it can warn the caller about the TN change. If it is a service provider that did the ENUM query and it has billing relationship with the caller or can bill the caller directly or indirectly, it can inform the caller about the increase of the call charge and give the caller the choice to accept/deny the call. - Don't route to that TN. Continue routing using the previous TN. James > -----Original Message----- > From: Lawrence Conroy [mailto:lwc@roke.co.uk] > Sent: Saturday, February 16, 2002 12:23 PM > To: paf@cisco.com > Cc: enum@ietf.org > Subject: [Enum] Re. 2916bis > > > At 8:59 pm +0100 15/2/02, Patrik F�ltstr�m wrote: > >I have here compiled a list of things to be changed to RFC 2916 when > >2916bis is created. > > >(8) Examples must be corrected and made made clear. For > example, there > >should be absolutely no confusion about (?that?) full regular > >expressions are used. > >I.e. any delimiter and any matching mechanism can be used > > To which I reply: > I am having major trouble (apart from just reading the > DDDS collection :) > in finding answers to the following questions: > (i) Is there ever a need to have anything other than a "complete > replacement" as the rule substitution expression when applying an > ENUM query to the e164.arpa domain space? > > [Point (8) suggests that there is a need for full regular expressions > - I can't think of a case where this is needed.] > > (ii) Is there ever a need to use a non-terminal NAPTR record when > dealing with ENUM (e.164.arpa domain space) records? > > (iii) RFC2916 states that tel: URIs should be re-submitted to the > ENUM system, and that the Client is responsible for loop detection. > > Richard has suggested that this is not needed; a tel: URI should NOT > be re-submitted. On reflection, I agree with him - I can't think of a > particular reason why such a re-submission is needed either - can > anyone else think of a case? > > [If not, the required tel: flag document is not too hard, and there > may not *be* a problem with loops - it also solves Jon's concerns > from the sipping-e164 document, I think :] > > best regards, > Lawrence > -- > lwc@roke.co.uk: +44 1794 833666::: > > _______________________________________________ > 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 daemon@optimus.ietf.org Wed Feb 20 17:27:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22331 for ; Wed, 20 Feb 2002 17:27:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25647 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 17:27:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25080; Wed, 20 Feb 2002 17:18:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25050 for ; Wed, 20 Feb 2002 17:18:40 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22109 for ; Wed, 20 Feb 2002 17:18:35 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA20620; Wed, 20 Feb 2002 23:17:59 +0100 (MET) Date: Wed, 20 Feb 2002 23:03:14 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Yu, James" , "'Lawrence Conroy'" cc: enum@ietf.org Subject: RE: [Enum] Re. 2916bis Message-ID: <2852914.1014246194@localhost> In-Reply-To: <23309E398D84D5119D0F00306E075139ECEC5C@dc02.npac.com> References: <23309E398D84D5119D0F00306E075139ECEC5C@dc02.npac.com> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-20 15.38 -0600 "Yu, James" wrote: > So any valid TN can appear in the tel URL in the NAPTR RR, I see several > possible ways of handling that particular tel URL (TN) if the TN will > cause charging issue (a U.S. TN mapped to a Russian TN) You might have the same cost issues when you end up being gatewaying from one protocol (cheap) to another one (expensive). So, it is always important when doing gatewaying like this that even if the NAPTR have a priority that the called party can set, the calling party or someone which act on behalf of the called party _have_to_ apply a policy for what he accepts. In the IETF we say quite often that we have during the years developed quite a large number of guns, but just because I have one in my hand, I don't have to shoot myself in my left foot. Yes, misconfiguration of NAPTR for ENUM might create problems. Text about these things should go into the security consideration section of relevant documents. I can add something general in the 2916bis, but you who work with individual other things also have to think about these things. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 19:35:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24854 for ; Wed, 20 Feb 2002 19:35:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA02212 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 19:35:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01546; Wed, 20 Feb 2002 19:26:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01496 for ; Wed, 20 Feb 2002 19:26:45 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24741 for ; Wed, 20 Feb 2002 19:26:42 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 0CD933190C; Wed, 20 Feb 2002 16:26:14 -0800 (PST) To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "Yu, James" , "'Lawrence Conroy'" , enum@ietf.org Subject: Re: [Enum] Re. 2916bis In-Reply-To: Message from =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= of "Wed, 20 Feb 2002 23:03:14 +0100." <2852914.1014246194@localhost> Date: Wed, 20 Feb 2002 16:26:14 -0800 Message-ID: <18027.1014251174@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Forgive me, but could someone please explain why we need to say anything about NAPTR records in 2916bis? I thought this document defined a protocol for mapping E.164 numbers into domain names. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 23:09:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29472 for ; Wed, 20 Feb 2002 23:09:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA11473 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 23:09:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA10754; Wed, 20 Feb 2002 23:00:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA10682 for ; Wed, 20 Feb 2002 23:00:22 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29313 for ; Wed, 20 Feb 2002 23:00:17 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1L3xT013561; Wed, 20 Feb 2002 21:59:29 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 21:59:24 -0600 Message-ID: <23309E398D84D5119D0F00306E075139ECEC5F@dc02.npac.com> From: "Yu, James" To: "'Michael Mealling'" , Lawrence Conroy Cc: enum@ietf.org Subject: RE: [Enum] DDDS, DNS clarification needed? Date: Wed, 20 Feb 2002 21:59:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > > > > To which I add more questions on the TripleDS thicket: > > Question - is the AUS "+494023451234" or is it "494023451234"? > > The AUS is the second one. The '+' is extraneous here so its > removed to make the Key as simple as possible but still useable. > Mike, is it a typo? The AUS is the first one, "+494023451234." I believe that Patrik intentionally keep the "+" for the regular expression mapping use. James _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 23:15:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29596 for ; Wed, 20 Feb 2002 23:15:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA11821 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 23:15:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA11228; Wed, 20 Feb 2002 23:07:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA11197 for ; Wed, 20 Feb 2002 23:07:11 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29382 for ; Wed, 20 Feb 2002 23:07:04 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1L42rI2005645; Wed, 20 Feb 2002 23:02:53 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1L42nnI005644; Wed, 20 Feb 2002 23:02:49 -0500 (EST) Date: Wed, 20 Feb 2002 23:02:49 -0500 From: Michael Mealling To: "Yu, James" Cc: "'Michael Mealling'" , Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] DDDS, DNS clarification needed? Message-ID: <20020220230249.I26811@bailey.dscga.com> Reply-To: Michael Mealling References: <23309E398D84D5119D0F00306E075139ECEC5F@dc02.npac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23309E398D84D5119D0F00306E075139ECEC5F@dc02.npac.com> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Wed, Feb 20, 2002 at 09:59:23PM -0600, Yu, James wrote: > > > To which I add more questions on the TripleDS thicket: > > > Question - is the AUS "+494023451234" or is it "494023451234"? > > > > The AUS is the second one. The '+' is extraneous here so its > > removed to make the Key as simple as possible but still useable. > > > > Mike, is it a typo? The AUS is the first one, "+494023451234." I believe > that Patrik intentionally keep the "+" for the regular expression mapping > use. Yes. Your are correct. It roots the regexp so that you are sure you're matching on something that is a 'fully qualified' e164 number.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 20 23:16:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29613 for ; Wed, 20 Feb 2002 23:16:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA11835 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 23:16:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA11270; Wed, 20 Feb 2002 23:07:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA11239 for ; Wed, 20 Feb 2002 23:07:28 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29386 for ; Wed, 20 Feb 2002 23:07:23 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1L46u013759; Wed, 20 Feb 2002 22:06:56 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 22:06:50 -0600 Message-ID: <23309E398D84D5119D0F00306E075139ECEC61@dc02.npac.com> From: "Yu, James" To: "'Jim Reid'" Cc: enum@ietf.org Subject: RE: [Enum] Re. 2916bis Date: Wed, 20 Feb 2002 22:06:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA11240 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Jim, The process involves retrieving NAPTR RRs via DNS where the URLs (e.g., mailto URL or e-mail address and SIP URL, etc.) are part of the NAPTR RRs (in the regular expression field). In addition, ENUM, as a DDDS application, also provides the mechanism/foundation for many ENUM applications (e.g., SIP, VPIM). So it should describe something that can be used by all the ENUM applications and leave specifics to each ENUM application. James > -----Original Message----- > From: Jim Reid [mailto:Jim.Reid@nominum.com] > Sent: Wednesday, February 20, 2002 7:26 PM > To: Patrik F�ltstr�m > Cc: Yu, James; 'Lawrence Conroy'; enum@ietf.org > Subject: Re: [Enum] Re. 2916bis > > > Forgive me, but could someone please explain why we need to say > anything about NAPTR records in 2916bis? I thought this document > defined a protocol for mapping E.164 numbers into domain names. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 00:02:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00739 for ; Thu, 21 Feb 2002 00:02:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA14503 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 00:02:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13515; Wed, 20 Feb 2002 23:53:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13486 for ; Wed, 20 Feb 2002 23:53:32 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00624 for ; Wed, 20 Feb 2002 23:53:27 -0500 (EST) Received: from [193.118.192.111] (HELO [158.152.16.98]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062665; Thu, 21 Feb 2002 04:53:30 +0000 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <23309E398D84D5119D0F00306E075139ECEC61@dc02.npac.com> References: <23309E398D84D5119D0F00306E075139ECEC61@dc02.npac.com> Date: Thu, 21 Feb 2002 04:39:18 +0000 To: "Yu, James" , "'Jim Reid'" From: Lawrence Conroy Subject: RE: [Enum] Re. 2916bis Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 10:06 pm -0600 20/2/02, Yu, James wrote: > >In addition, ENUM, as a DDDS application, also provides the >mechanism/foundation for many ENUM applications (e.g., SIP, VPIM). So it > To which I reply: I'm not comfortable with the terms here (specifically the nasty overload of "application"). I had thought that "ENUM" included more than just the client application making the query. As such I tend to use the term "ENUM Application" to be analogous with the program running on the ENUM client. As for SIP, VPIM, ... I don't view of them as ENUM applications - at best they're protocols that can be used to further resolve URIs returned by the ENUM Application. That, however, is what happens AFTER the DDDS algorithm has done its stuff. Does that make sense? All the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 00:02:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00761 for ; Thu, 21 Feb 2002 00:02:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA14533 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 00:02:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13636; Wed, 20 Feb 2002 23:53:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13522 for ; Wed, 20 Feb 2002 23:53:35 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00626 for ; Wed, 20 Feb 2002 23:53:30 -0500 (EST) Received: from [193.118.192.111] (HELO [158.152.16.98]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062666; Thu, 21 Feb 2002 04:53:34 +0000 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <23309E398D84D5119D0F00306E075139ECEC5C@dc02.npac.com> References: <23309E398D84D5119D0F00306E075139ECEC5C@dc02.npac.com> Date: Thu, 21 Feb 2002 04:51:46 +0000 To: "Yu, James" From: Lawrence Conroy Subject: RE: [Enum] Re. 2916bis Cc: enum@ietf.org, paf@cisco.com, richard.stastny@oefeg.at Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 3:38 pm -0600 20/2/02, Yu, James wrote: >For (iii), one good example is a non-geographical number (e.g., toll free >number) that is mapped to a POTS number (geographical number). There may be >a "need" to re-submit. To which I reply: That was my initial thought, but I have been convinced that CNAMEs work quite well in most circumstances. If you want to just do a Non-Geo number translation, I think that you can just put a CNAME to the "real" number. (Thanks to Richard Stastny & Patrik for that one). In this case, there is no need to re-submit on receipt of a tel: URL, as you won't get there until the NS and CNAMEs have been processed, transparent to DDDS. If anyone DOESN'T think that CNAMEs can be used, please holler. best regards, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 01:47:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01913 for ; Thu, 21 Feb 2002 01:47:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28207 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 01:47:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27912; Thu, 21 Feb 2002 01:38:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27880 for ; Thu, 21 Feb 2002 01:38:39 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01780 for ; Thu, 21 Feb 2002 01:38:33 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id HAA04094; Thu, 21 Feb 2002 07:37:52 +0100 (MET) Date: Thu, 21 Feb 2002 07:19:14 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Yu, James" , "'Michael Mealling'" , Lawrence Conroy cc: enum@ietf.org Subject: RE: [Enum] DDDS, DNS clarification needed? Message-ID: <4638544.1014275954@localhost> In-Reply-To: <23309E398D84D5119D0F00306E075139ECEC5F@dc02.npac.com> References: <23309E398D84D5119D0F00306E075139ECEC5F@dc02.npac.com> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-20 21.59 -0600 "Yu, James" wrote: > I believe > that Patrik intentionally keep the "+" for the regular expression mapping > use. That was the intention, yes. If one reuse NAPTR for for example private dialing plans, then one might want to have some way in the regexp to detect a E.164 number and ENUM, and that was why I kept the '+'. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 04:10:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11427 for ; Thu, 21 Feb 2002 04:10:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA05849 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 04:10:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05349; Thu, 21 Feb 2002 04:01:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05318 for ; Thu, 21 Feb 2002 04:01:44 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11293 for ; Thu, 21 Feb 2002 04:01:41 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.224]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g1L91XtS012441; Thu, 21 Feb 2002 10:01:36 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Feb 2002 09:45:46 +0100 Message-ID: From: "Stastny, Richard" To: "'Christian Huitema'" Cc: enum@ietf.org Date: Thu, 21 Feb 2002 09:45:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemma) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Christian wrote: > My personal conclusion is that ENUM look-up SHOULD NOT be > performed "in > real-time" during call set-up, since there is ambiguity about the > I fully agree, but this is an issue, where a lot of different opinions are around. IMHO it should by stated clearly in RFC2916whatever, that (at least public;-) ENUM is NOT PART of the call setup, that it happens before call setup. This is VERY important in legal context and also related to the technical requirements. Regarding the legal context, if ENUM is NOT PART of the call setup, it is not part of eventually regulated voice calls, there is no requiremnt of LI, etc. Technically it is not part of the telephony infrastructure and therefore ITU-T E.105 is not relevant. This also makes sense, because AFTER the ENUM lookup the user may still decide to send an e-mail or do not user the result of the query at all. Of course I am aware, that some operators (especially mobile operators) are considering to use ENUM-like services within their networks DURING call setup, with the end user(s) on both ends not even aware of the fact, that ENUM-like services are used. But this is not (public) ENUM and up to the operator. regards Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Wednesday, February 20, 2002 5:36 PM > To: Stastny, Richard; Clive D.W. Feather; Lawrence Conroy > Cc: enum@ietf.org > Subject: Implementer's dilemma (was RE: [Enum] DDDS, DNS clarification > needed?) > > > > I don not fully understand this discussion. Considering the Zillions > of > > parameters already existing in operation systems and applications, I > do > > not > > see the problem in including the ENUM Root Domain in the > Application. > Or > > the > > other way round, if I had to write an ENUM Add-on to Outlook, > Netmeeting > > or > > Messenger, the first thing I would implement is a parameter for the > ENUM > > Root Domain (also considering that the discussion is still > not settled > > discussion between IAB and ITU), and second I would implement > additional > > optional parameters for other root domains: e.g. if an number is > entered > > with +, I would go to ENUM Root, with 000 also, any number without 0 > or + > > to > > a private root, etc. > > Alternately, whoever has to write such an interface to ENUM might just > wait a little for the dust to settle? I believe that there are two > issues to resolve before implementers feel comfortable with ENUM: > > 1) There is a usability issue to determine when a telephone number has > to be resolved as an identifier (i.e. through ENUM) versus as > a routing > index (i.e. through the routing protocol proposed by the INTEL group): > ring that device versus ring the owner of the device. > > 2) There is a cost benefit issue to determine whether paying > the cost of > an ENUM look-up (potentially a second or two) is worth the benefit > (finding useful information). > > My personal conclusion is that ENUM look-up SHOULD NOT be > performed "in > real-time" during call set-up, since there is ambiguity about the > meaning of entering a phone number in a call procedure and there is a > large probability, at least in the initial phase, that the > ENUM database > will not hold any information for a specific number; real-time call > redirection, if needed, can always be performed by the target of the > call, or by the last switch. If I was to implement any > support for ENUM, > it would be in an "off-line" procedure e.g. an add-on to the > management > of the local address book. Now, if you think "off-line", it > is very easy > to look in multiple databases and let the user choose. > > -- Christian Huitema > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 04:22:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11687 for ; Thu, 21 Feb 2002 04:22:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA06627 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 04:22:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06030; Thu, 21 Feb 2002 04:13:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06000 for ; Thu, 21 Feb 2002 04:13:26 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11502 for ; Thu, 21 Feb 2002 04:13:23 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 2615A3190C; Thu, 21 Feb 2002 01:12:55 -0800 (PST) To: "Yu, James" Cc: enum@ietf.org Subject: Re: [Enum] Re. 2916bis In-Reply-To: Message from "Yu, James" of "Wed, 20 Feb 2002 22:06:49 CST." <23309E398D84D5119D0F00306E075139ECEC61@dc02.npac.com> Date: Thu, 21 Feb 2002 01:12:55 -0800 Message-ID: <28908.1014282775@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >>>>> "James" == Yu, James writes: James> Jim, The process involves retrieving NAPTR RRs via DNS James> where the URLs (e.g., mailto URL or e-mail address and SIP James> URL, etc.) are part of the NAPTR = RRs (in the regular James> expression field). Indeed. But what has any of that got to do with the mapping of E.164 numbers to domain names? ENUM tells me how to enter my phone number in the DNS. It shouldn't (have to) tell me what record types or data are required for that number's DNS representation. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 04:25:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11739 for ; Thu, 21 Feb 2002 04:25:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA06867 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 04:25:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06301; Thu, 21 Feb 2002 04:17:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06272 for ; Thu, 21 Feb 2002 04:17:02 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11580 for ; Thu, 21 Feb 2002 04:16:58 -0500 (EST) X-nextra-fallback-rcpt: Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.224]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g1L9GwtR013942 for ; Thu, 21 Feb 2002 10:16:59 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Feb 2002 09:51:27 +0100 Message-ID: From: "Stastny, Richard" To: "'enum@ietf.org'" Subject: FW: [Enum] DDDS, DNS clarification needed? Date: Thu, 21 Feb 2002 09:51:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Clarification: As I understood the discussion within ITU-T SG2, the question from the ITU-T point of view is not 1 or 2 or many roots, its 0 or 1;-) regards Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com > -----Original Message----- > From: Shaw, Robert [mailto:Robert.Shaw@itu.int] > Sent: Wednesday, February 20, 2002 6:01 PM > To: 'Randy Bush' > Cc: enum@ietf.org > Subject: RE: [Enum] DDDS, DNS clarification needed? > > > > the idea of different e164.foos is great. it should be used > > to map the different global numbering plans, you know, the > ones where > > north america is +42, +666, etc. for the nonce, we will > use e164.arpa > > to map the current prosaic global numbering plan, where > north america > > is +1. > > > > btw, when will the itu be publishing these alternate > numbering plans? > > > > Huh? Interesting leap of logic... > > Randy, the real world has this habit of defying one's > instinctive or even one's strongly held engineering > beliefs. > > A coordinated hierarchical symbol set (to use 2826 > terminology) does not a priori require a single > technical root. In the PSTN world, that's a simple > fact and proof that one can have a coordinated > hierarchical addressing system that is not dependent > upon a single technical root. > > A disadvantage of this model is that it requires a > much more complex level of coordination among various > systems; made more difficult with telecoms > liberalization and the growth in facilities-based > carriers. > > I know that it's a difficult transition for some but > the issues are deeper and go beyond technical > elegance of pulling a symbol set from one central > computer or switch somewhere. There are other factors such > as real world geopolitics, national sovereignty over critical > infrastructure, CI security issues, intercept, etc. > > If you make the mental leap that discussing where ENUM is > rooted a priori implies a non-coordinated country code symbol > space, then I'd have to say that I'd disagree with your > assumption. > > Bob > > _______________________________________________ > 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 daemon@optimus.ietf.org Thu Feb 21 05:05:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12445 for ; Thu, 21 Feb 2002 05:05:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10404 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 05:06:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09435; Thu, 21 Feb 2002 04:57:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09404 for ; Thu, 21 Feb 2002 04:57:13 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12293 for ; Thu, 21 Feb 2002 04:57:10 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA00105 for ; Thu, 21 Feb 2002 10:56:41 +0100 (MET) Date: Thu, 21 Feb 2002 10:55:13 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org Message-ID: <5416099.1014288913@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Enum] 2916bis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit A lot of people (including myself) is talking about the magic 2916bis document. And, noone can really start working constructive comments or adjacent papers until I have a first draft of the document. Now, the good news is that I have a co-editor, Michael Mealling, and we together have a first version of the draft ready. Or rather, we have the draft in pieces on the floor, and Michael is "just" to put them together. I expect that to only take a day or so (else I will do it myself) so you will see a 2916bis draft really soon now. Note: We have been working on it the last couple of days, so many of your comments the last days have not been incorporated. So, I ask you to remember what you said in email and review the draft when it is released, and at that time bring up the issue again if you are not happy. Regards, Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 07:16:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14611 for ; Thu, 21 Feb 2002 07:16:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16148 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 07:16:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15618; Thu, 21 Feb 2002 07:03:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15592 for ; Thu, 21 Feb 2002 07:03:26 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14268 for ; Thu, 21 Feb 2002 07:03:23 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062694 for ; Thu, 21 Feb 2002 12:03:24 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: Date: Thu, 21 Feb 2002 12:03:21 +0000 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] NAPTR RS sub-field field and why it's there Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Folks, I am looking at the contents of the NAPTR fields and how they might be used in an implementation. When the user "fires up" the ENUM program, passing it an E.164 number, it's pretty obvious that it wants the program to accept an E.164 number and return a URI (or URIs) - that's what the program does, extracting information from the DNS as needed. Thus it seems to me that the RS part of the Services field in a NAPTR only confirms that this record is intended for use in a program that accepts E.164 numbers and returns a URI (in short, ENUM). It can be used internally by the ENUM application to drop any NAPTR record it retrieves that has another RS value, but there's no earthly reason to pass it back up to the user. Is this correct, or am I missing something? best regards, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 08:55:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17163 for ; Thu, 21 Feb 2002 08:55:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22002 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 08:55:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21234; Thu, 21 Feb 2002 08:45:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21203 for ; Thu, 21 Feb 2002 08:45:13 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16786 for ; Thu, 21 Feb 2002 08:45:08 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1LDeSI2006582; Thu, 21 Feb 2002 08:40:28 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1LDeNp9006581; Thu, 21 Feb 2002 08:40:23 -0500 (EST) Date: Thu, 21 Feb 2002 08:40:23 -0500 From: Michael Mealling To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: "Yu, James" , "'Michael Mealling'" , Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] DDDS, DNS clarification needed? Message-ID: <20020221084023.J26811@bailey.dscga.com> Reply-To: Michael Mealling References: <23309E398D84D5119D0F00306E075139ECEC5F@dc02.npac.com> <4638544.1014275954@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4638544.1014275954@localhost> User-Agent: Mutt/1.3.22.1i Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit On Thu, Feb 21, 2002 at 07:19:14AM +0100, Patrik F�ltstr�m wrote: > --On 2002-02-20 21.59 -0600 "Yu, James" wrote: > > I believe > > that Patrik intentionally keep the "+" for the regular expression mapping > > use. > > That was the intention, yes. If one reuse NAPTR for for example private > dialing plans, then one might want to have some way in the regexp to detect > a E.164 number and ENUM, and that was why I kept the '+'. See! He is smarter than I am! ;-) -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 08:58:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17387 for ; Thu, 21 Feb 2002 08:58:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22435 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 08:58:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21520; Thu, 21 Feb 2002 08:50:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21491 for ; Thu, 21 Feb 2002 08:50:07 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16985 for ; Thu, 21 Feb 2002 08:50:00 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1LDjqI2006600; Thu, 21 Feb 2002 08:45:52 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1LDjprr006599; Thu, 21 Feb 2002 08:45:51 -0500 (EST) Date: Thu, 21 Feb 2002 08:45:51 -0500 From: Michael Mealling To: Jim Reid Cc: "Yu, James" , enum@ietf.org Subject: Re: [Enum] Re. 2916bis Message-ID: <20020221084550.K26811@bailey.dscga.com> Reply-To: Michael Mealling References: <23309E398D84D5119D0F00306E075139ECEC61@dc02.npac.com> <28908.1014282775@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28908.1014282775@shell.nominum.com> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Thu, Feb 21, 2002 at 01:12:55AM -0800, Jim Reid wrote: > >>>>> "James" == Yu, James writes: > James> Jim, The process involves retrieving NAPTR RRs via DNS > James> where the URLs (e.g., mailto URL or e-mail address and SIP > James> URL, etc.) are part of the NAPTR = RRs (in the regular > James> expression field). > > Indeed. But what has any of that got to do with the mapping of E.164 > numbers to domain names? ENUM tells me how to enter my phone number in > the DNS. It shouldn't (have to) tell me what record types or data are > required for that number's DNS representation. Umm... I think you might be mistaken in your definition of ENUM. ENUM isn't about storing telephone number _in_ the DNS, its about using the DNS to find available services for a given TN. Those services are encoded in the form of URIs and Service descriptions. If you just want a standard for putting TNs into DNS zones then ENUM isn't what you're looking for... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 09:05:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17580 for ; Thu, 21 Feb 2002 09:05:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA23220 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 09:05:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22134; Thu, 21 Feb 2002 08:56:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22053 for ; Thu, 21 Feb 2002 08:56:24 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17181 for ; Thu, 21 Feb 2002 08:56:17 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1LDptI2006631; Thu, 21 Feb 2002 08:51:55 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1LDpq6c006630; Thu, 21 Feb 2002 08:51:52 -0500 (EST) Date: Thu, 21 Feb 2002 08:51:52 -0500 From: Michael Mealling To: Lawrence Conroy Cc: enum@ietf.org Subject: Re: [Enum] NAPTR RS sub-field field and why it's there Message-ID: <20020221085152.L26811@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Thu, Feb 21, 2002 at 12:03:21PM +0000, Lawrence Conroy wrote: > Hi Folks, > I am looking at the contents of the NAPTR fields and how they might > be used in an implementation. When the user "fires up" the ENUM > program, passing it an E.164 number, it's pretty obvious that it wants > the program to accept an E.164 number and return a URI (or URIs) - that's > what the program does, extracting information from the DNS as needed. > > Thus it seems to me that the RS part of the Services field in a NAPTR only > confirms that this record is intended for use in a program that accepts > E.164 numbers and returns a URI (in short, ENUM). It can be used internally > by the ENUM application to drop any NAPTR record it retrieves that has > another > RS value, but there's no earthly reason to pass it back up to the user. > > Is this correct, or am I missing something? I think you would be correct if we kept the Services field as is, e.g. 'E2U'. But there is some desire among some definition of majority that ENUM's Service definition is to flat. Thus you could start seeing Services that, while still discussing the fact that the input is E.164 and the output is a URI, denote that the Service in question is for Voice Mail while this other one is for a Voice Call, and that this other one is for a Fax Call. The other change is that the relationship between the protocol in the Service field and the URI scheme also needs work. For example, the protocol could be 'smtp' while the URI scheme was 'mailto'. Or the protocol might be 'apex' and the URI scheme would be 'im'. So, you are correct but possibly only for now. So if I were designing an API I would plan for this possibility. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 09:05:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17604 for ; Thu, 21 Feb 2002 09:05:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA23234 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 09:05:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22108; Thu, 21 Feb 2002 08:56:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22036 for ; Thu, 21 Feb 2002 08:56:03 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17179 for ; Thu, 21 Feb 2002 08:55:58 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1LDtIZ24569; Thu, 21 Feb 2002 05:55:18 -0800 (PST) Received: from CHSHARP-W2K1.cisco.com (rtp-vpn2-105.cisco.com [10.82.240.105]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA23385; Thu, 21 Feb 2002 05:55:24 -0800 (PST) Message-Id: <4.3.2.7.2.20020221075910.04a0f260@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Feb 2002 08:54:51 -0500 To: "Stastny, Richard" From: Chip Sharp Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemma) Cc: "'Christian Huitema'" , enum@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Stating that the protocols & algorithms defined in RFC2916 should not be part of call setup could be part of an applicability statement for RFC2916 (or its successor), but there is no reason to put such a restrictive statement in the protocol definition itself. RFC 2916 defines protocols & algorithms, not a service (especially in the ITU sense of the word). RFC2916 does not define (and ENUM isn't) a telecommunications service. Using RFC2916 procedures during call setup is a decision for a person or organization to make when setting up their network (or service). Of course, anyone thinking of using RFC2916 during call setup (as understood by traditional telephony) should analyze the implications (some of which were mentioned by Christian) to determine if it will meet requirements. This analysis could be included in an applicability statement. Chip At 03:45 AM 2/21/2002, Stastny, Richard wrote: >Christian wrote: >> My personal conclusion is that ENUM look-up SHOULD NOT be >> performed "in >> real-time" during call set-up, since there is ambiguity about the >> > >I fully agree, but this is an issue, where a lot of different opinions are >around. > >IMHO it should by stated clearly in RFC2916whatever, that (at least >public;-) ENUM is NOT PART of the call setup, that it happens before call >setup. >This is VERY important in legal context and also related to the technical >requirements. Regarding the legal context, if ENUM is NOT PART of the call >setup, it is not part of eventually regulated voice calls, there is no >requiremnt of LI, etc. Technically it is not part of the telephony >infrastructure and therefore ITU-T E.105 is not relevant. > >This also makes sense, because AFTER the ENUM lookup the user may still >decide to send an e-mail or do not user the result of the query at all. > >Of course I am aware, that some operators (especially mobile operators) are >considering to use ENUM-like services within their networks DURING call >setup, with the end user(s) on both ends not even aware of the fact, that >ENUM-like services are used. But this is not (public) ENUM and up to the >operator. > >regards > > >Richard STASTNY >OeFEG >Arsenal Objekt 24 >P.O. Box 147 >A-1103 Vienna, Austria > >Tel: +43 664 420 4100 >Fax: +43 1 79780 13 >richard.stastny@oefeg.at >richard@stastny.com > > >> -----Original Message----- >> From: Christian Huitema [mailto:huitema@windows.microsoft.com] >> Sent: Wednesday, February 20, 2002 5:36 PM >> To: Stastny, Richard; Clive D.W. Feather; Lawrence Conroy >> Cc: enum@ietf.org >> Subject: Implementer's dilemma (was RE: [Enum] DDDS, DNS clarification >> needed?) >> >> >> > I don not fully understand this discussion. Considering the Zillions >> of >> > parameters already existing in operation systems and applications, I >> do >> > not >> > see the problem in including the ENUM Root Domain in the >> Application. >> Or >> > the >> > other way round, if I had to write an ENUM Add-on to Outlook, >> Netmeeting >> > or >> > Messenger, the first thing I would implement is a parameter for the >> ENUM >> > Root Domain (also considering that the discussion is still >> not settled >> > discussion between IAB and ITU), and second I would implement >> additional >> > optional parameters for other root domains: e.g. if an number is >> entered >> > with +, I would go to ENUM Root, with 000 also, any number without 0 >> or + >> > to >> > a private root, etc. >> >> Alternately, whoever has to write such an interface to ENUM might just >> wait a little for the dust to settle? I believe that there are two >> issues to resolve before implementers feel comfortable with ENUM: >> >> 1) There is a usability issue to determine when a telephone number has >> to be resolved as an identifier (i.e. through ENUM) versus as >> a routing >> index (i.e. through the routing protocol proposed by the INTEL group): >> ring that device versus ring the owner of the device. >> >> 2) There is a cost benefit issue to determine whether paying >> the cost of >> an ENUM look-up (potentially a second or two) is worth the benefit >> (finding useful information). >> >> My personal conclusion is that ENUM look-up SHOULD NOT be >> performed "in >> real-time" during call set-up, since there is ambiguity about the >> meaning of entering a phone number in a call procedure and there is a >> large probability, at least in the initial phase, that the >> ENUM database >> will not hold any information for a specific number; real-time call >> redirection, if needed, can always be performed by the target of the >> call, or by the last switch. If I was to implement any >> support for ENUM, >> it would be in an "off-line" procedure e.g. an add-on to the >> management >> of the local address book. Now, if you think "off-line", it >> is very easy >> to look in multiple databases and let the user choose. >> >> -- Christian Huitema >> > >_______________________________________________ >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 daemon@optimus.ietf.org Thu Feb 21 09:28:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18249 for ; Thu, 21 Feb 2002 09:28:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24826 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 09:28:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24029; Thu, 21 Feb 2002 09:20:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23984 for ; Thu, 21 Feb 2002 09:20:04 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18024 for ; Thu, 21 Feb 2002 09:19:59 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1LECJI2006749; Thu, 21 Feb 2002 09:12:19 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1LECIgv006748; Thu, 21 Feb 2002 09:12:18 -0500 (EST) Date: Thu, 21 Feb 2002 09:12:17 -0500 From: Michael Mealling To: Chip Sharp Cc: "Stastny, Richard" , "'Christian Huitema'" , enum@ietf.org Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemma) Message-ID: <20020221091217.N26811@bailey.dscga.com> Reply-To: Michael Mealling References: <4.3.2.7.2.20020221075910.04a0f260@dogwood.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20020221075910.04a0f260@dogwood.cisco.com> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Thu, Feb 21, 2002 at 08:54:51AM -0500, Chip Sharp wrote: > Stating that the protocols & algorithms defined in RFC2916 should not > be part of call setup could be part of an applicability statement for > RFC2916 (or its successor), but there is no reason to put such a > restrictive statement in the protocol definition itself. > > RFC 2916 defines protocols & algorithms, not a service (especially in > the ITU sense of the word). RFC2916 does not define (and ENUM isn't) a > telecommunications service. > Using RFC2916 procedures during call setup is a decision for a person > or organization to make when setting up their network (or service). > > Of course, anyone thinking of using RFC2916 during call setup (as > understood by traditional telephony) should analyze the implications > (some of which were mentioned by Christian) to determine if it will > meet requirements. This analysis could be included in an applicability > statement. I hate to do the 'me too' thing but I was in the process of saying just about the same thing when this came by, thus saving me the time. But I do want to make sure the viewpoint is supported. ENUM (rfc2916bis) is a very simple definition that you then take and do profiles of within your application. IMHO, ENUM should never even mention the words 'call setup', 'telephone call', etc anywhere in the document (except possibly in the Examples). The same goes for SIP.... -MM > At 03:45 AM 2/21/2002, Stastny, Richard wrote: > >Christian wrote: > >> My personal conclusion is that ENUM look-up SHOULD NOT be > >> performed "in > >> real-time" during call set-up, since there is ambiguity about the > >> > > > >I fully agree, but this is an issue, where a lot of different opinions are > >around. > > > >IMHO it should by stated clearly in RFC2916whatever, that (at least > >public;-) ENUM is NOT PART of the call setup, that it happens before call > >setup. > >This is VERY important in legal context and also related to the technical > >requirements. Regarding the legal context, if ENUM is NOT PART of the call > >setup, it is not part of eventually regulated voice calls, there is no > >requiremnt of LI, etc. Technically it is not part of the telephony > >infrastructure and therefore ITU-T E.105 is not relevant. > > > >This also makes sense, because AFTER the ENUM lookup the user may still > >decide to send an e-mail or do not user the result of the query at all. > > > >Of course I am aware, that some operators (especially mobile operators) are > >considering to use ENUM-like services within their networks DURING call > >setup, with the end user(s) on both ends not even aware of the fact, that > >ENUM-like services are used. But this is not (public) ENUM and up to the > >operator. > > > >regards > > > > > >Richard STASTNY > >OeFEG > >Arsenal Objekt 24 > >P.O. Box 147 > >A-1103 Vienna, Austria > > > >Tel: +43 664 420 4100 > >Fax: +43 1 79780 13 > >richard.stastny@oefeg.at > >richard@stastny.com > > > > > >> -----Original Message----- > >> From: Christian Huitema [mailto:huitema@windows.microsoft.com] > >> Sent: Wednesday, February 20, 2002 5:36 PM > >> To: Stastny, Richard; Clive D.W. Feather; Lawrence Conroy > >> Cc: enum@ietf.org > >> Subject: Implementer's dilemma (was RE: [Enum] DDDS, DNS clarification > >> needed?) > >> > >> > >> > I don not fully understand this discussion. Considering the Zillions > >> of > >> > parameters already existing in operation systems and applications, I > >> do > >> > not > >> > see the problem in including the ENUM Root Domain in the > >> Application. > >> Or > >> > the > >> > other way round, if I had to write an ENUM Add-on to Outlook, > >> Netmeeting > >> > or > >> > Messenger, the first thing I would implement is a parameter for the > >> ENUM > >> > Root Domain (also considering that the discussion is still > >> not settled > >> > discussion between IAB and ITU), and second I would implement > >> additional > >> > optional parameters for other root domains: e.g. if an number is > >> entered > >> > with +, I would go to ENUM Root, with 000 also, any number without 0 > >> or + > >> > to > >> > a private root, etc. > >> > >> Alternately, whoever has to write such an interface to ENUM might just > >> wait a little for the dust to settle? I believe that there are two > >> issues to resolve before implementers feel comfortable with ENUM: > >> > >> 1) There is a usability issue to determine when a telephone number has > >> to be resolved as an identifier (i.e. through ENUM) versus as > >> a routing > >> index (i.e. through the routing protocol proposed by the INTEL group): > >> ring that device versus ring the owner of the device. > >> > >> 2) There is a cost benefit issue to determine whether paying > >> the cost of > >> an ENUM look-up (potentially a second or two) is worth the benefit > >> (finding useful information). > >> > >> My personal conclusion is that ENUM look-up SHOULD NOT be > >> performed "in > >> real-time" during call set-up, since there is ambiguity about the > >> meaning of entering a phone number in a call procedure and there is a > >> large probability, at least in the initial phase, that the > >> ENUM database > >> will not hold any information for a specific number; real-time call > >> redirection, if needed, can always be performed by the target of the > >> call, or by the last switch. If I was to implement any > >> support for ENUM, > >> it would be in an "off-line" procedure e.g. an add-on to the > >> management > >> of the local address book. Now, if you think "off-line", it > >> is very easy > >> to look in multiple databases and let the user choose. > >> > >> -- Christian Huitema > >> > > > >_______________________________________________ > >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 -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 09:30:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18314 for ; Thu, 21 Feb 2002 09:30:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25056 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 09:30:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24230; Thu, 21 Feb 2002 09:21:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24132 for ; Thu, 21 Feb 2002 09:21:37 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18055 for ; Thu, 21 Feb 2002 09:21:33 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA28288; Thu, 21 Feb 2002 15:21:32 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA01538; Thu, 21 Feb 2002 15:21:24 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id <1JWY1QSL>; Thu, 21 Feb 2002 15:21:29 +0100 Message-ID: From: Brandner Rudolf To: "'Michael Mealling'" Cc: Conroy Lawrence , enum@ietf.org Subject: AW: [Enum] NAPTR RS sub-field field and why it's there Date: Thu, 21 Feb 2002 15:21:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > On Thu, Feb 21, 2002 at 12:03:21PM +0000, Lawrence Conroy wrote: > > Hi Folks, > > I am looking at the contents of the NAPTR fields and how > they might > > be used in an implementation. When the user "fires up" the ENUM > > program, passing it an E.164 number, it's pretty obvious > that it wants > > the program to accept an E.164 number and return a URI (or > URIs) - that's > > what the program does, extracting information from the DNS > as needed. > > > > Thus it seems to me that the RS part of the Services field > in a NAPTR only > > confirms that this record is intended for use in a program > that accepts > > E.164 numbers and returns a URI (in short, ENUM). It can be > used internally > > by the ENUM application to drop any NAPTR record it > retrieves that has > > another > > RS value, but there's no earthly reason to pass it back up > to the user. > > > > Is this correct, or am I missing something? > > I think you would be correct if we kept the Services field as > is, e.g. 'E2U'. > But there is some desire among some definition of majority that ENUM's > Service definition is to flat. Thus you could start seeing > Services that, > while still discussing the fact that the input is E.164 and the output > is a URI, denote that the Service in question is for Voice > Mail while this > other one is for a Voice Call, and that this other one is for > a Fax Call. > The other change is that the relationship between the protocol in the > Service field and the URI scheme also needs work. For example, the > protocol could be 'smtp' while the URI scheme was 'mailto'. Or the > protocol might be 'apex' and the URI scheme would be 'im'. > > So, you are correct but possibly only for now. So if I were designing > an API I would plan for this possibility. > > -MM > What about dropping the E2U in the Service Field? Example: "sip" instead of "sip+E2U" or "mailto" instead of "mailto+E2U" etc. I understand that there are potential different services the retrieved NAPTR is for, but isn't the E2U just redundant because the application just used ENUM (the E2U service) to retrieve that said NAPTR? Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 09:34:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18479 for ; Thu, 21 Feb 2002 09:34:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25690 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 09:34:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24630; Thu, 21 Feb 2002 09:26:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24584 for ; Thu, 21 Feb 2002 09:25:57 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18165 for ; Thu, 21 Feb 2002 09:25:53 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1LEOT182422; Thu, 21 Feb 2002 06:24:29 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202211424.g1LEOT182422@nic-naa.net> To: "Stastny, Richard" cc: "'Christian Huitema'" , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemma) In-Reply-To: Your message of "Thu, 21 Feb 2002 09:45:39 +0100." Date: Thu, 21 Feb 2002 09:24:29 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org My head hurts. > This is VERY important in legal context and also related to the technical > requirements. Regarding the legal context, if ENUM is NOT PART of the call > setup, it is not part of eventually regulated voice calls, there is no > requiremnt of LI, etc. Technically it is not part of the telephony > infrastructure and therefore ITU-T E.105 is not relevant. Somewhere there is an instance of bind, responding to queries. The data the instance of bind uses has a temporal property (TTL value). While valid, two temporally distinct identical queries yeild identical responses. During the intervening temporal period the network fabric between the resolver and the mapped address could have partitioned. Resolution may be successfully accomplished, even if there is no route to host. One of the aspects of one of the "keyword" or "alternate root" offerings made elsewhere (not on this list) that interested me was the similarity between interposition (on the dns) and legal intercept. In the vendor case I became familiar with, a UA formed a string (with infix dots), heuristics concerning the string (terminating dot-bounded substring value) caused the UA to (eventually) serially query responders located at the vendor-partners facilities in three North American sites, not the M root server, which is more proximal. The "intercept" occurred at the UA/resolver interface, in the form of query modification with redirection, rather than query replication with redirection. The interested can read rfc2804 for the technical critique of interposition and related complexity and access model issues. It also occurred at the set of query responders I fail to see how resolution (ENUM) is part of transport (call setup). I fail to see how legal intercept (query replication and/or redirection) can be implemented outside of the resolver or nameserver, if the lookup function (dns queries) are within the scope for intercept. Did someone actually make the case that ENUM is "call setup"? I'd appreciate a pointer to the item in the archive. Did someone discuss how they plan to implement LI in ENUM? Ditto. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 10:06:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19544 for ; Thu, 21 Feb 2002 10:06:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27175 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 10:06:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26527; Thu, 21 Feb 2002 09:57:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26500 for ; Thu, 21 Feb 2002 09:57:18 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19255 for ; Thu, 21 Feb 2002 09:57:14 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1LEt8223981; Thu, 21 Feb 2002 09:56:02 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Feb 2002 08:54:47 -0600 Message-ID: <23309E398D84D5119D0F00306E075139ECEC65@dc02.npac.com> From: "Yu, James" To: "'Lawrence Conroy'" Cc: enum@ietf.org Subject: RE: [Enum] Re. 2916bis Date: Thu, 21 Feb 2002 08:54:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > I had thought that "ENUM" included more than just the client > application making > the query. As such I tend to use the term "ENUM Application" to be > analogous with > the program running on the ENUM client. > > As for SIP, VPIM, ... > I don't view of them as ENUM applications - at best they're > protocols that > can be used to further resolve URIs returned by the ENUM > Application. That, > however, is what happens AFTER the DDDS algorithm has done its stuff. > What I meant for "ENUM application" is an application/software that invokes ENUM to retrieve URLs it can use. Certainly, SIP and VPIM are the protocols or specific instance of protocols (e.g., LDAP schema). The real applications are the call processing and voice messaging. I talk about SIP as if it represents the applications behind it. James _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 10:24:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20173 for ; Thu, 21 Feb 2002 10:24:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28232 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 10:24:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27579; Thu, 21 Feb 2002 10:14:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27548 for ; Thu, 21 Feb 2002 10:14:14 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19783 for ; Thu, 21 Feb 2002 10:14:08 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.224]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g1LFDxtQ014741; Thu, 21 Feb 2002 16:14:04 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Feb 2002 15:59:41 +0100 Message-ID: From: "Stastny, Richard" To: "'Eric Brunner-Williams in Portland Maine'" , "Stastny, Richard" Cc: "'Christian Huitema'" , enum@ietf.org Subject: RE: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) Date: Thu, 21 Feb 2002 15:59:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Did someone actually make the case that ENUM is "call setup"? > I'd appreciate > a pointer to the item in the archive. Did someone discuss how > they plan to > implement LI in ENUM? Ditto. If you look at the presentation from Robert Khello, Ericsson at the ENUM Workshop held in Copenhagen by ERO/ETO www.eto.dk , you will see on page 6 and 7 that the ENUM query is done by the MMS Application Server in the network. Although the exaples are for messaging, the same applies also for Voice calls, as he confirmed. If the network is doing the ENUM query and not the user client, it is done IMHO during the call setup from the user pont of view. Two statements from the contribution of China 011-Q1 to the January SG2 meeting on: DISCUSSION ON ESTABLISHING A TLD SPECIAL FOR ENUM IMPLEMENTATION: Quote1: In practice, ENUM is a framework making use of Internet DNS for providing SCP-like function used in circuit-switching network. End Quote1 Quote2: With the development of ENUM, the amount of domain name resolution will be very large. However, voice communication requires high real time performance. The speed of resolution will be a key aspect for ENUM development. Speeding up the resolution will be propitious to the development of ENUM. End Quote2. During the discussion, China argued that they consider to use ENUM within their telephony network during call setup, and that it is therefore very important to reduce the call setup delay by having the ENUM Root in a TLD and not in a SLD. (No, I do not want to comment this, but it was nice to watch Patrik's and Jim's faces when China explained to them how the root server network works). Regarding LI: of course I know, that you cannot LI an DNS query, but I have seen the term on so-called Issues with ENUM List. I also got the question from a regulator, if it is possuble to block the access to ENUM, or to parts of ENUM. You should be aware, that currently a lot of people out there, who are discussing very seriously about ENUM, have no idea how the Internet, SIP or DNS works (not to talk about the DDDS drafts, they gave me an headache ;-) PS: Eric, I send you the above mentioned documents with separate e-mail. Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com > -----Original Message----- > From: Eric Brunner-Williams in Portland Maine > [mailto:brunner@nic-naa.net] > Sent: Thursday, February 21, 2002 3:24 PM > To: Stastny, Richard > Cc: 'Christian Huitema'; enum@ietf.org; brunner@nic-naa.net > Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's > dilemma) > > > My head hurts. > > > This is VERY important in legal context and also related to > the technical > > requirements. Regarding the legal context, if ENUM is NOT > PART of the call > > setup, it is not part of eventually regulated voice calls, > there is no > > requiremnt of LI, etc. Technically it is not part of the telephony > > infrastructure and therefore ITU-T E.105 is not relevant. > > Somewhere there is an instance of bind, responding to > queries. The data the > instance of bind uses has a temporal property (TTL value). > While valid, two > temporally distinct identical queries yeild identical > responses. During the > intervening temporal period the network fabric between the > resolver and the > mapped address could have partitioned. > > Resolution may be successfully accomplished, even if there is > no route to > host. > > One of the aspects of one of the "keyword" or "alternate > root" offerings > made elsewhere (not on this list) that interested me was the > similarity > between interposition (on the dns) and legal intercept. > > In the vendor case I became familiar with, a UA formed a > string (with infix > dots), heuristics concerning the string (terminating > dot-bounded substring > value) caused the UA to (eventually) serially query > responders located at > the vendor-partners facilities in three North American sites, > not the M root > server, which is more proximal. > > The "intercept" occurred at the UA/resolver interface, in the > form of query > modification with redirection, rather than query replication > with redirection. > The interested can read rfc2804 for the technical critique of > interposition > and related complexity and access model issues. It also > occurred at the set > of query responders > > I fail to see how resolution (ENUM) is part of transport (call setup). > > I fail to see how legal intercept (query replication and/or > redirection) > can be implemented outside of the resolver or nameserver, if > the lookup > function (dns queries) are within the scope for intercept. > > Did someone actually make the case that ENUM is "call setup"? > I'd appreciate > a pointer to the item in the archive. Did someone discuss how > they plan to > implement LI in ENUM? Ditto. > > Eric > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 11:00:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21932 for ; Thu, 21 Feb 2002 11:00:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00917 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 11:00:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00187; Thu, 21 Feb 2002 10:51:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00162 for ; Thu, 21 Feb 2002 10:51:22 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21409 for ; Thu, 21 Feb 2002 10:51:19 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1LFo1182952; Thu, 21 Feb 2002 07:50:01 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202211550.g1LFo1182952@nic-naa.net> To: "Stastny, Richard" cc: "'Eric Brunner-Williams in Portland Maine'" , "'Christian Huitema'" , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) In-Reply-To: Your message of "Thu, 21 Feb 2002 15:59:34 +0100." Date: Thu, 21 Feb 2002 10:50:01 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Richard, > During the discussion, China argued that they consider to use ENUM within > their telephony network during call setup, and that it is therefore very > important to reduce the call setup delay by having the ENUM Root in a TLD > and not in a SLD. (No, I do not want to comment this, but it was nice to > watch Patrik's and Jim's faces when China explained to them how the root > server network works). The example I mentioned was motivated by some observations I didn't include: a bug in a UA's handling of a particular encoding, and the cost of "overseas bandwidth". Common to each is the phenomena that every reference to the dns for name labels or name-label-like strings which used a generating set larger than the well-known set of 63 distinct values would (exit the dns, but that isn't this issue, except when card(.) != 1), and incure trans-pacific tarrif and latency properties (this issue). The first quote (ENUM-is-SCP) fails to appreciate generality, e.g., mailto or avian carrier. Its author doesn't actually say the-application-is-the-transport, only that it is used. The second quote could be read as bandwith/latency sensitive, not simply as ENUM-is-setup, and adequately addressed by the deployment of secondary servers, independent of the namespace. The Jim is our own Jim Reid, neh? Who was the "China" explaining to he and Patrik? Urk. A power-point and a MSWord doc. Thanks. First time I've seen exmh say "Very Large Message", then again, 5.88 MB means "I've got MAIL". Thanks, Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 11:38:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23486 for ; Thu, 21 Feb 2002 11:38:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03836 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 11:38:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02805; Thu, 21 Feb 2002 11:28:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02771 for ; Thu, 21 Feb 2002 11:27:56 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23028 for ; Thu, 21 Feb 2002 11:27:52 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1LGP6226337; Thu, 21 Feb 2002 11:25:30 -0500 Message-Id: <5.1.0.14.2.20020221112038.041eaae0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 11:23:33 -0500 To: Lawrence Conroy , "Yu, James" From: Richard Shockey Subject: RE: [Enum] Re. 2916bis Cc: enum@ietf.org, paf@cisco.com, richard.stastny@oefeg.at In-Reply-To: References: <23309E398D84D5119D0F00306E075139ECEC5C@dc02.npac.com> <23309E398D84D5119D0F00306E075139ECEC5C@dc02.npac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 04:51 AM 2/21/2002 +0000, Lawrence Conroy wrote: >At 3:38 pm -0600 20/2/02, Yu, James wrote: >>For (iii), one good example is a non-geographical number (e.g., toll free >>number) that is mapped to a POTS number (geographical number). There may be >>a "need" to re-submit. > > >To which I reply: > That was my initial thought, but I have been convinced that CNAMEs work >quite well in most circumstances. If you want to just do a Non-Geo number >translation, I think that you can just put a CNAME to the "real" number. >(Thanks to Richard Stastny & Patrik for that one). > >In this case, there is no need to re-submit on receipt of a tel: URL, >as you won't get there until the NS and CNAMEs have been processed, >transparent to DDDS. > >If anyone DOESN'T think that CNAMEs can be used, please holler. Yes but we have previously had discussions (pittsburg i recall) that the use of CNAME and DNAME are very dangerous if not configured correctly and as we know the vast majority of DNS errors are in configuration. Its not that you cant do this ..its just that you have to be very very careful and there was consensus before that doing this within the root domain e164.arpa is a "bad thing". I'll let randy comment further if necessary. >best regards, > Lawrence >-- >lwc@roke.co.uk: +44 1794 833666::: > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 11:40:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23561 for ; Thu, 21 Feb 2002 11:39:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03921 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 11:40:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03216; Thu, 21 Feb 2002 11:30:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03185 for ; Thu, 21 Feb 2002 11:30:54 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23130 for ; Thu, 21 Feb 2002 11:30:49 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062706; Thu, 21 Feb 2002 16:30:44 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <20020221085152.L26811@bailey.dscga.com> References: <20020221085152.L26811@bailey.dscga.com> Date: Thu, 21 Feb 2002 16:30:34 +0000 To: Michael Mealling From: Lawrence Conroy Subject: Re: [Enum] NAPTR RS sub-field field and why it's there Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Folks, I reply (rather more warmly than normal - apologies in advance, gentle readers): At 8:51 am -0500 21/2/02, Michael Mealling wrote: >On Thu, Feb 21, 2002 at 12:03:21PM +0000, Lawrence Conroy wrote: >> Hi Folks, >> I am looking at the contents of the NAPTR fields and how they might >> be used in an implementation. When the user "fires up" the ENUM >> program, passing it an E.164 number, it's pretty obvious that it wants >> the program to accept an E.164 number and return a URI (or URIs) - that's >> what the program does, extracting information from the DNS as needed. >> >> Thus it seems to me that the RS part of the Services field in a NAPTR only >> confirms that this record is intended for use in a program that accepts >> E.164 numbers and returns a URI (in short, ENUM). It can be used internally >> by the ENUM application to drop any NAPTR record it retrieves that has >> another >> RS value, but there's no earthly reason to pass it back up to the user. >> >> Is this correct, or am I missing something? > >I think you would be correct if we kept the Services field as is, e.g. 'E2U'. >But there is some desire among some definition of majority that ENUM's >Service definition is to flat. Thus you could start seeing Services that, >while still discussing the fact that the input is E.164 and the output >is a URI, denote that the Service in question is for Voice Mail while this >other one is for a Voice Call, and that this other one is for a Fax Call. Ugly conflation and potentially unnecessary IMHO. Resolution Service is pretty strange, and with the conflations some folk have proposed it's just plain confusing. As you suggested a few posts ago, it can eaasly be used to assert that a NAPTR is for use only with specific Resolution Service, so if a DDDS application gets a NAPTR back with an unrecognised RS value, it drops it on the floor - thus it's an Application Collision Avoidance mechanism. Fine. However, with the conflation ideas floating up, this makes the job of writing a sensible application quite hard. Do I have to update all of the ENUM applications out in the field because someone has invented a new "service" value of E2BONGOBONGOVIDEOPLUSSURROUND? I fear so. Without this stuff, I just pass back the URI and protocol/treatment values and let the caller' system decide what to do with them. >The other change is that the relationship between the protocol in the >Service field and the URI scheme also needs work. For example, the >protocol could be 'smtp' while the URI scheme was 'mailto'. Or the >protocol might be 'apex' and the URI scheme would be 'im'. Agreed that the names 'Resolution Service' and 'Protocol' are badly out of whack. However, that is not all. AFAIK, each DDDS application has to specify the Services field syntax it will expect (and so is responsible for [re-]defining RS and Protocol and any other sub-fields). This is not too good - I'd suggest that the "template" DDDS document defines a default, and allows an application that needs a different Services field syntax to "opt out" rather than the current cut-and-paste. Whilst you're at this, why not re-consider the names of these sub-fields. I guess that there will be a number of documents that have to specify and request registration for what we now call RS and protocol sub-fields. Having these names doesn't help the reader to fathom out what exactly the purpose for which they're being used, IMHO. I've already ranted enough on RS. I feel that even protocol is not perfect - there are times when we don't actually involve an IP-based protocol to further resolution or use of the URI. We've been having discussions "in-house" on this, and treatment may be closer to how it may be used. >So, you are correct but possibly only for now. So if I were designing >an API I would plan for this possibility. In either case, I understand that a 'protocol' value may WELL be passed back to the caller of the ENUM application, so that this, plus the URI, can be used to decide on further handling. I just don't think that the RS value has any reason to be passed back. >-MM > >-- >-------------------------------------------------------------------------------- >Michael Mealling | Vote Libertarian! | urn:pin:1 >michael@neonym.net | | http://www.neonym.net -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 11:59:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24387 for ; Thu, 21 Feb 2002 11:59:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04859 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 11:59:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04448; Thu, 21 Feb 2002 11:50:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04417 for ; Thu, 21 Feb 2002 11:50:19 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23998 for ; Thu, 21 Feb 2002 11:50:15 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062709; Thu, 21 Feb 2002 16:50:16 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <200202211550.g1LFo1182952@nic-naa.net> References: <200202211550.g1LFo1182952@nic-naa.net> Date: Thu, 21 Feb 2002 16:50:12 +0000 To: Eric Brunner-Williams in Portland Maine , "Stastny, Richard" From: Lawrence Conroy Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) Cc: "'Eric Brunner-Williams in Portland Maine'" , "'Christian Huitema'" , enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 10:50 am -0500 21/2/02, Eric Brunner-Williams in Portland Maine wrote: >Richard, > >> During the discussion, China argued that they consider to use ENUM within >> their telephony network during call setup, and that it is therefore very >> important to reduce the call setup delay by having the ENUM Root in a TLD >> and not in a SLD. (No, I do not want to comment this, but it was nice to >> watch Patrik's and Jim's faces when China explained to them how the root >> server network works). > >The example I mentioned was motivated by some observations I didn't include: >a bug in a UA's handling of a particular encoding, and the cost of "overseas >bandwidth". Common to each is the phenomena that every reference to the dns >for name labels or name-label-like strings which used a generating set larger >than the well-known set of 63 distinct values would (exit the dns, but that >isn't this issue, except when card(.) != 1), and incure trans-pacific tarrif >and latency properties (this issue). > >The first quote (ENUM-is-SCP) fails to appreciate generality, e.g., mailto >or avian carrier. >Its author doesn't actually say the-application-is-the-transport, only that >it is used. > >The second quote could be read as bandwith/latency sensitive, not simply >as ENUM-is-setup, and adequately addressed by the deployment of secondary >servers, independent of the namespace. To which I add: actually, 3GPP include an allusion to ENUM in the IMS documents (TS23.228 - a word doc, I'm afraid, so I'll let you retrieve it from ftp.3gpp.org). This is also in the call setup procedures and is not done by the Mobile. Thus I tend to agree with Chip; whether or not ENUM is initiated within the call setup sequence is an applicability issue, not one for 2916. BTW (mindful that this is an IETF list, so apologies for the inappropriate content): (i) it's IP traffic so it's covered by CALEA (or RIPA over here), right? (ii) do you really expect and answer to "how do you do it if it's decentralised" ? all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 12:05:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24818 for ; Thu, 21 Feb 2002 12:05:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06322 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 12:05:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04737; Thu, 21 Feb 2002 11:57:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04701 for ; Thu, 21 Feb 2002 11:57:08 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24259 for ; Thu, 21 Feb 2002 11:57:01 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1LGqoI2007461; Thu, 21 Feb 2002 11:52:50 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1LGql5U007460; Thu, 21 Feb 2002 11:52:47 -0500 (EST) Date: Thu, 21 Feb 2002 11:52:47 -0500 From: Michael Mealling To: Lawrence Conroy Cc: Michael Mealling , enum@ietf.org Subject: Re: [Enum] NAPTR RS sub-field field and why it's there Message-ID: <20020221115247.D6933@bailey.dscga.com> Reply-To: Michael Mealling References: <20020221085152.L26811@bailey.dscga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Thu, Feb 21, 2002 at 04:30:34PM +0000, Lawrence Conroy wrote: > At 8:51 am -0500 21/2/02, Michael Mealling wrote: > >On Thu, Feb 21, 2002 at 12:03:21PM +0000, Lawrence Conroy wrote: > >> Hi Folks, > >> I am looking at the contents of the NAPTR fields and how they might > >> be used in an implementation. When the user "fires up" the ENUM > >> program, passing it an E.164 number, it's pretty obvious that it wants > >> the program to accept an E.164 number and return a URI (or URIs) - that's > >> what the program does, extracting information from the DNS as needed. > >> > >> Thus it seems to me that the RS part of the Services field in a NAPTR only > >> confirms that this record is intended for use in a program that accepts > >> E.164 numbers and returns a URI (in short, ENUM). It can be used > >> internally by the ENUM application to drop any NAPTR record it retrieves > >> that has another RS value, but there's no earthly reason to pass it back > >> up to the user. > >> > >> Is this correct, or am I missing something? > > > >I think you would be correct if we kept the Services field as is, e.g. > >'E2U'. But there is some desire among some definition of majority that > >ENUM's Service definition is to flat. Thus you could start seeing Services > >that, while still discussing the fact that the input is E.164 and the output > >is a URI, denote that the Service in question is for Voice Mail while this > >other one is for a Voice Call, and that this other one is for a Fax Call. > > Ugly conflation and potentially unnecessary IMHO. For your applications, maybe. The request has been voiced to me at just about every IETF meeting since RFC 2916 came out... > Resolution Service is pretty strange, and with the conflations some folk > have proposed it's just plain confusing. As you suggested a few posts ago, > it can eaasly be used to assert that a NAPTR is for use only with specific > Resolution Service, so if a DDDS application gets a NAPTR back with an > unrecognised RS value, it drops it on the floor - thus it's an Application > Collision Avoidance mechanism. Fine. > > However, with the conflation ideas floating up, this makes the job of > writing a sensible application quite hard. Do I have to update all of > the ENUM applications out in the field because someone has invented a > new "service" value of E2BONGOBONGOVIDEOPLUSSURROUND? I fear so. > > Without this stuff, I just pass back the URI and protocol/treatment > values and let the caller' system decide what to do with them. That might be fine if you had control over them but how does the callers system know what to do with a URI of the form: mailto:michael@foo.com Can you send it voice mail? Is it my regular text email address? Am I currently listening to it? The point being, a URI by itself doesn't tell you what its actually supposed to be used _for_. > >The other change is that the relationship between the protocol in the > >Service field and the URI scheme also needs work. For example, the > >protocol could be 'smtp' while the URI scheme was 'mailto'. Or the > >protocol might be 'apex' and the URI scheme would be 'im'. > > Agreed that the names 'Resolution Service' and 'Protocol' are badly > out of whack. However, that is not all. > > AFAIK, each DDDS application has to specify the Services field syntax > it will expect (and so is responsible for [re-]defining RS and Protocol > and any other sub-fields). This is not too good - I'd suggest that the > "template" DDDS document defines a default, and allows an application > that needs a different Services field syntax to "opt out" rather than > the current cut-and-paste. I could but that makes it to easy for different Applications to start copying from each other and IMHO that leads to more work doing collision avoidance. I would much rather each Application have to at least think about it than just hand them a default... > Whilst you're at this, why not re-consider the names of these sub-fields. > I guess that there will be a number of documents that have to specify > and request registration for what we now call RS and protocol sub-fields. > Having these names doesn't help the reader to fathom out what exactly > the purpose for which they're being used, IMHO. > > I've already ranted enough on RS. I feel that even protocol is not perfect > - there are times when we don't actually involve an IP-based protocol > to further resolution or use of the URI. We've been having discussions > "in-house" on this, and treatment may be closer to how it may be used. Sure. Nothing here requires IP. Heck, ENUM could specify another database besides DNS eventually and still have the same procedures apply. But I think 'protocol' is generic enough. I think you may be giving the word more weight than was intended. I've been working on the DDDS documents way to long to rip 'em apart yet again. ;-) > >So, you are correct but possibly only for now. So if I were designing > >an API I would plan for this possibility. > > In either case, I understand that a 'protocol' value may WELL be passed > back to the caller of the ENUM application, so that this, plus the URI, > can be used to decide on further handling. I just don't think that the > RS value has any reason to be passed back. I'm just saying that is still up for discussion. See: http://search.ietf.org/internet-drafts/draft-walter-ranalli-enum-service-01.txt for an example... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 12:54:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26584 for ; Thu, 21 Feb 2002 12:54:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14922 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 12:54:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14386; Thu, 21 Feb 2002 12:45:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14361 for ; Thu, 21 Feb 2002 12:45:26 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26124 for ; Thu, 21 Feb 2002 12:45:23 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA00799; Thu, 21 Feb 2002 12:44:53 -0500 (EST) Received: from arutkowski-desk.verisign.com (ARUTKOWSKI-DESK [10.131.128.39]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15YHTL4M; Thu, 21 Feb 2002 12:45:35 -0500 Message-Id: <5.1.0.14.2.20020221123154.00b708d0@vsvapostal1.prod.netsol.com> X-Sender: trutkowski@vsvapostal1.prod.netsol.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 12:44:49 -0500 To: Lawrence Conroy From: Tony Rutkowski Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) Cc: enum@ietf.org In-Reply-To: References: <200202211550.g1LFo1182952@nic-naa.net> <200202211550.g1LFo1182952@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:50 AM 2/21/2002, Lawrence Conroy wrote: >(i) it's IP traffic so it's covered by CALEA (or RIPA over here), right? Definitely by RIPA, as well as the Council resolution. As to LI, it's definitely covered under Title 18 as modified by the Patriot Act. As to CALEA, probably - although Chip argues for some kind of creative escape. :-) --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 12:59:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26775 for ; Thu, 21 Feb 2002 12:59:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15317 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 12:59:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14735; Thu, 21 Feb 2002 12:51:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14704 for ; Thu, 21 Feb 2002 12:51:11 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26418 for ; Thu, 21 Feb 2002 12:51:08 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g1LHpAu27507 for enum@ietf.org; Thu, 21 Feb 2002 12:51:10 -0500 (EST) Date: Thu, 21 Feb 2002 12:51:10 -0500 (EST) From: Scott Bradner Message-Id: <200202211751.g1LHpAu27507@newdev.harvard.edu> To: enum@ietf.org Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:50 AM 2/21/2002, Lawrence Conroy wrote: >(i) it's IP traffic so it's covered by CALEA (or RIPA over here), right? while this is interesting it is not all that related to the working group that this mailing list was set up to support please refrain from discussing this type of unrelated non-technical issue on this list Scott _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 13:12:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27449 for ; Thu, 21 Feb 2002 13:12:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16616 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 13:12:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15929; Thu, 21 Feb 2002 13:03:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15898 for ; Thu, 21 Feb 2002 13:03:52 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26961 for ; Thu, 21 Feb 2002 13:03:50 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA01711; Thu, 21 Feb 2002 13:03:16 -0500 (EST) Received: from arutkowski-desk.verisign.com (ARUTKOWSKI-DESK [10.131.128.39]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15YHTMFC; Thu, 21 Feb 2002 13:03:59 -0500 Message-Id: <5.1.0.14.2.20020221125656.00bbc1b0@vsvapostal1.prod.netsol.com> X-Sender: trutkowski@vsvapostal1.prod.netsol.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 13:03:12 -0500 To: Scott Bradner , enum@ietf.org From: Tony Rutkowski Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) In-Reply-To: <200202211751.g1LHpAu27507@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Scott, >while this is interesting it is not all that related to the working group >that this mailing list was set up to support > >please refrain from discussing this type of unrelated non-technical >issue on this list It's highly related and quite technical. However, you no doubt meant to say that pursuant to RFC2804, it is out-of-scope for IETF. The operational and technical requirements and implementations are being done elsewhere out of respect to the decision in 2804. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 13:16:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27566 for ; Thu, 21 Feb 2002 13:16:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16828 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 13:16:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16209; Thu, 21 Feb 2002 13:06:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16176 for ; Thu, 21 Feb 2002 13:06:53 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27120 for ; Thu, 21 Feb 2002 13:06:50 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g1LI6qX27558; Thu, 21 Feb 2002 13:06:52 -0500 (EST) Date: Thu, 21 Feb 2002 13:06:52 -0500 (EST) From: Scott Bradner Message-Id: <200202211806.g1LI6qX27558@newdev.harvard.edu> To: enum@ietf.org, sob@harvard.edu, trutkowski@verisign.com Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Tony sez: > It's highly related and quite technical. However, you > no doubt meant to say that pursuant to RFC2804, it > is out-of-scope for IETF. The operational and technical > requirements and implementations are being done elsewhere > out of respect to the decision in 2804. no doubt that I did not mean that - strangely enough I meant what I said Scott _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 13:23:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27918 for ; Thu, 21 Feb 2002 13:23:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17282 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 13:23:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16730; Thu, 21 Feb 2002 13:15:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16699 for ; Thu, 21 Feb 2002 13:15:07 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27522 for ; Thu, 21 Feb 2002 13:15:04 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1LIDt228906 for ; Thu, 21 Feb 2002 13:14:19 -0500 Message-Id: <5.1.0.14.2.20020220194456.022017d0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 13:08:29 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] A short reminder on naming conventions for ID's to this WG.... Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org All ID to this WG should be considered personal until there is WG consensus that they are part of the WG activity therefore in the future. As a reminder, the convention for personal ID's is draft-[author]-[subject].txt Official ENUM WG documents will be labeled.... draft-ietf-enum-[subject].txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 13:28:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28169 for ; Thu, 21 Feb 2002 13:28:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17617 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 13:28:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17086; Thu, 21 Feb 2002 13:19:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17056 for ; Thu, 21 Feb 2002 13:19:48 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27732 for ; Thu, 21 Feb 2002 13:19:45 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1LIEK228914; Thu, 21 Feb 2002 13:14:44 -0500 Message-Id: <5.1.0.14.2.20020221120158.0409cd98@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 13:16:02 -0500 To: Lawrence Conroy , Eric Brunner-Williams in Portland Maine , "Stastny, Richard" From: Richard Shockey Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) Cc: "'Eric Brunner-Williams in Portland Maine'" , "'Christian Huitema'" , enum@ietf.org In-Reply-To: References: <200202211550.g1LFo1182952@nic-naa.net> <200202211550.g1LFo1182952@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > >To which I add: > actually, 3GPP include an allusion to ENUM in the IMS documents > (TS23.228 - >a word doc, I'm afraid, so I'll let you retrieve it from ftp.3gpp.org). > >This is also in the call setup procedures and is not done by the Mobile. I've been scratching my head over this thread..... so can some one define what is "call setup procedures" ??? Is there some common definition here? I've always looked at ENUM as a globally authoritive database that can convert a name (E.164 number) into a list of possible services. ENUM could be part of a set of databases or tables ( local or otherwise) that can assist a network element in making a decision on how to potentially terminate (route or switch) a particular media stream. How and when a look up occurs could be nearly anywhere depending on the network configuration and the pathway by which the media stream originates. >Thus I tend to agree with Chip; whether or not ENUM is initiated within >the call setup sequence is an applicability issue, not one for 2916. > >BTW (mindful that this is an IETF list, so apologies for the inappropriate >content): >(i) it's IP traffic so it's covered by CALEA (or RIPA over here), right? >(ii) do you really expect and answer to "how do you do it if it's >decentralised" ? > >all the best, > Lawrence >-- >lwc@roke.co.uk: +44 1794 833666::: > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 13:41:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28744 for ; Thu, 21 Feb 2002 13:41:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18918 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 13:41:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18359; Thu, 21 Feb 2002 13:32:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18328 for ; Thu, 21 Feb 2002 13:32:48 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28405 for ; Thu, 21 Feb 2002 13:32:45 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA03209; Thu, 21 Feb 2002 13:32:11 -0500 (EST) Received: from arutkowski-desk.verisign.com (ARUTKOWSKI-DESK [10.131.128.39]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15YHTNAZ; Thu, 21 Feb 2002 13:32:53 -0500 Message-Id: <5.1.0.14.2.20020221131753.02565540@vsvapostal1.prod.netsol.com> X-Sender: trutkowski@vsvapostal1.prod.netsol.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 13:31:29 -0500 To: Scott Bradner , enum@ietf.org From: Tony Rutkowski Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) In-Reply-To: <200202211806.g1LI6qX27558@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >no doubt that I did not mean that - strangely enough I meant what I said Hi Scott, Then you have no problem with discussing ENUM support for the ETSI TR 101 944 technical requirements functions and service interfaces, as well as support of CII IAP functions that are part of TIA/EIA/IS-J-STD-025 interface? These are mandatory requirements. This was the gist of the original exchange. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 14:01:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29594 for ; Thu, 21 Feb 2002 14:01:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20180 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 14:01:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19419; Thu, 21 Feb 2002 13:52:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19388 for ; Thu, 21 Feb 2002 13:52:06 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29189 for ; Thu, 21 Feb 2002 13:52:03 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g1LIq4527937; Thu, 21 Feb 2002 13:52:04 -0500 (EST) Date: Thu, 21 Feb 2002 13:52:04 -0500 (EST) From: Scott Bradner Message-Id: <200202211852.g1LIq4527937@newdev.harvard.edu> To: enum@ietf.org, sob@harvard.edu, trutkowski@verisign.com Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > Then you have no problem with discussing ENUM support for the > ETSI TR 101 944 technical requirements functions and service > interfaces, as well as support of CII IAP functions that are > part of TIA/EIA/IS-J-STD-025 interface? These are mandatory > requirements. sorry - my random character string translator is broken this wg is about how to use the DNS to perform a function if there is a question about (for example) monitoring that exchange it is not an enum question - it is a dns question - and does not belong on this list Scott _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 14:10:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00025 for ; Thu, 21 Feb 2002 14:10:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20811 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 14:10:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20245; Thu, 21 Feb 2002 14:01:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20212 for ; Thu, 21 Feb 2002 14:01:27 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29616 for ; Thu, 21 Feb 2002 14:01:24 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1LIxx183580; Thu, 21 Feb 2002 10:59:59 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202211859.g1LIxx183580@nic-naa.net> To: Tony Rutkowski cc: Scott Bradner , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) In-Reply-To: Your message of "Thu, 21 Feb 2002 13:31:29 EST." <5.1.0.14.2.20020221131753.02565540@vsvapostal1.prod.netsol.com> Date: Thu, 21 Feb 2002 13:59:59 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > This was the gist of the original exchange. False. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 15:40:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03165 for ; Thu, 21 Feb 2002 15:40:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24875 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 15:40:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24380; Thu, 21 Feb 2002 15:31:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24280 for ; Thu, 21 Feb 2002 15:30:52 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02613 for ; Thu, 21 Feb 2002 15:30:47 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA11448 for ; Thu, 21 Feb 2002 21:30:17 +0100 (MET) Date: Thu, 21 Feb 2002 21:29:12 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org Message-ID: <7698459.1014326952@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Enum] 2916bis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Here is the first version of the 2916bis document. Note, it is _NOT_ submitted to the Internet-Draft archive yet. It will be before cut-off tomorrow (friday). This is so you can give _fast_ constructive comments that we might have time to update before the cutoff. Otherwise (default) is for me to collect issues you all have and send them to Richard so they end up being discussion points. As you can see there are three important changes from RFC 2916: (1) The service field in the NAPTR is now the following service_field = [ "E2U" 1*("+" enumservice)] This is _NOT_ backward compatible. Reason for this is that one could register for example sipvoice, sipgaming and sipimpp and then have the service field which is E2U+sipvoice+sipgaming+sipimpp (2) A registration is mandatory for _any_ service which is added to the E2U facet (3) An empty flag field in the NAPTR is allowed, and means that another lookup is to be done, i.e. we don't force all NAPTR to be terminal There are probably inconsistencies in the document, because Michael and myself have worked hard on both getting this done, being active on the mailing list _and_ updating according to comments on the mailing list. 2916bis will be a recycle on proposed, because too many changes are needed to go to draft standard. paf Network Working Group P. Faltstrom Internet-Draft Cisco Systems Inc Expires: August 22, 2002 M. Mealling VeriSign February 21, 2002 The E.164 to URI DDDS Application draft-ietf-enum-rfc2916bis-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 22, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC WWWW. It is very important to note that it is impossible to read and understand this document without reading the documents discused in RFC WWWW. Faltstrom & Mealling Expires August 22, 2002 [Page 1] Internet-Draft ENUM February 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Use for these mechanisms for private dialing plans . . . . 3 1.3 Application of local policy . . . . . . . . . . . . . . . 3 2. The ENUM Application Specifications . . . . . . . . . . . 4 2.1 Application Unique String . . . . . . . . . . . . . . . . 4 2.2 First Well Known Rule . . . . . . . . . . . . . . . . . . 4 2.3 Expected Output . . . . . . . . . . . . . . . . . . . . . 4 2.4 Valid Databases . . . . . . . . . . . . . . . . . . . . . 4 2.4.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4.2 Services Parameters . . . . . . . . . . . . . . . . . . . 5 2.4.2.1 ENUM Services . . . . . . . . . . . . . . . . . . . . . . 6 3. Registration mechanism for ENUM Services . . . . . . . . . 7 3.1 Registration Requirements . . . . . . . . . . . . . . . . 7 3.1.1 Functionality Requirement . . . . . . . . . . . . . . . . 7 3.1.2 Naming requirement . . . . . . . . . . . . . . . . . . . . 7 3.1.3 Security requirement . . . . . . . . . . . . . . . . . . . 7 3.1.4 Publication Requirements . . . . . . . . . . . . . . . . . 8 3.2 Registration procedure . . . . . . . . . . . . . . . . . . 8 3.2.1 IANA Registration . . . . . . . . . . . . . . . . . . . . 8 3.2.1.1 Location of ENUM Service Registrations . . . . . . . . . . 8 3.2.1.2 Change Control . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2 Registration Template . . . . . . . . . . . . . . . . . . 9 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 14 References . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15 Full Copyright Statement . . . . . . . . . . . . . . . . . 17 Faltstrom & Mealling Expires August 22, 2002 [Page 2] Internet-Draft ENUM February 2002 1. Introduction Through transformation of E.164 numbers into DNS names and the use of existing DNS services like delegation through NS records, and use of NAPTR records in DNS, one can look up what services are available for a specific domain name in a decentralized way with distributed management of the different levels in the lookup process. The domain "e164.arpa" is being populated in order to provide the infrastructure in DNS for storage of E.164 numbers. In order to facilitate distributed operations, this domain is divided into subdomains. Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator in order to be listed, by examining the SOA resource record associated with the zone, just like in normal DNS operations. Of course, as with other domains, policies for such listings will be controlled on a subdomain basis and may differ in different parts of the world. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. All capitalized terms are taken from the vocabulary found in the DDDS algorithm specification found in RFC ZZZZ [3]. 1.2 Use for these mechanisms for private dialing plans This document specify how "ENUM" works, that is how to handle numbers allocated according to the ITU-T standard E.164. But, a similar mechanism can be used also for other numbers, such as private dialing plans. Suggested change is that (a) a different domain, well-known for all parties using the same dialing plan, is selected and (b) the application unique string (see section 3.1 below) is to be the full number as specified but without the leading '+'. 1.3 Application of local policy The priority field in the NAPTR is a request from the holder of the E.164 in what order the records are to be used. It is to be noted that the party looking up the records MAY apply a local policy for in what order the records are to be used based on a combination of the service fields and URI schemes. Faltstrom & Mealling Expires August 22, 2002 [Page 3] Internet-Draft ENUM February 2002 2. The ENUM Application Specifications This template defines the ENUM DDDS Application according to the rules and requirements found in [3]. The DDDS database used by this Application is found in [4] which is the document that defines the NAPTR DNS Resource Record type. 2.1 Application Unique String The Application Unique String is a fully qualified E.164 number minus any non-digit characters except for the '+' character which appears at the beginning of the number. The "+" is kept to provide a well understood anchor for the AUS in order to distinguish it from other telephone numbers that are not part of the E.164 namespace. 2.2 First Well Known Rule The First Well Known Rule for this Application is the identity rule. The output of this rule is the same as the input. This is because the E.164 namespace is organized in such a way that it is possible to go directly from the name to the smallest granularity of the namespace directly from the name itself. 2.3 Expected Output The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the 'absoluteURI' production in the Collected ABNF found in RFC2396 [7]. 2.4 Valid Databases At present only one DDDS Database is specified for this Application. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" (RFC ZZZZ) [4] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain-names. The output of the First Well Known Rule for the ENUM Application is the E.164 number minus all non-digit characters except for the +. In order to convert this to a unique key in this Database the string is converted into a domain-name according to this algorithm: 1. Remove all characters with the exception of the digits. Example: 4689761234 2. Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 3. Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 Faltstrom & Mealling Expires August 22, 2002 [Page 4] Internet-Draft ENUM February 2002 4. Append the string ".e164.arpa" to the end. Example: 4.3.2.1.6.7.9.8.6.4.e164.arpa This domain-name is used to request NAPTR records which produces new keys in the form of domain-names. DNS servers MAY interpret Flag values and use that information to include appropriate SRV and A records in the Additional Information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See the Additional Information Processing section of RFC YYYY for more information on NAPTR records and the Additional Information section of a DNS response packet. The character set used to encode the substitution expression is UTF- 8. The allowed input characters are all those characters that are allowed anywhere in a URI. The characters allowed to be in a Key are those that are currently defined for DNS domain-names. 2.4.1 Flags This Database contains a field that contains flags that signal when the DDDS algorithm has finished. At this time only one flag, "U", is defined. This means that this Rule is the last one and that the output of the Rule is a URI [7]. If a client encounters a record with an unknown flag, it MUST ignore it and move to the next Rule. This test takes precedence over any ordering since flags can control the interpretation placed on fields. A novel flag might change the interpretation of the regexp and/or replacement fields such that it is impossible to determine if a record matched a given target. If this flag is not present, clients must assume that another Rule exists at the Key produced by the current Rewrite Rule. 2.4.2 Services Parameters Service Parameters for this Application take the following form and are found in the Service field of the NAPTR record. service_field = [ "E2U" 1*("+" enumservice)] enumservice = ALPHA *31ALPHANUM ; The protocol and rs fields are limited to 32 ; characters and must start with an alphabetic. Faltstrom & Mealling Expires August 22, 2002 [Page 5] Internet-Draft ENUM February 2002 In other words, a non-optional "E2U" (used to denote ENUM only Rewrite Rules in order to mitigate record collisions) followed by 1 or more or more Enum Services which indicate what class of functionality a given end point offers. Each Enum Service is indicated by an initial '+' character. The empty string is also valid. This will typically be seen at the beginning of a series of Rules, when it is impossible to know what services and protocols will be offered at the end of a particular delegation path. 2.4.2.1 ENUM Services A service MUST be registered with the IANA via a description in an RFC. ENUM Services specifications contain the functional specification (i.e. what it can be used for), the valid protocols, and the URI schemes that may be returned. For example, the Enum Service "presence" would define the various URI schemes ("im:", "mailto:") can be used and what the service can be used for ("Where is the owner of this E.164 number?"). Another example might be "sipvoice" which specifies that the URI must use the 'sip:' URI scheme and use the SIP protocol to make a voice call (as opposed to a voice mail call or fax call). The only exception to the registration rule is for services used for experimental purposes, and those are to start with the facet "X-". These types are unregistered, experimental, and should be used only with the active agreement of the parties exchanging them. The registration mechanism is specified in Section 3. Faltstrom & Mealling Expires August 22, 2002 [Page 6] Internet-Draft ENUM February 2002 3. Registration mechanism for ENUM Services Registration of services requires approval by the IESG and publication of the service registration as some form of RFC. 3.1 Registration Requirements Service registration proposals are all expected to conform to various requirements laid out in the following sections. 3.1.1 Functionality Requirement A Service registered must be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means that the registration MUST specify what is expected when using that very NAPTR record, and the URI which is the outcome of the use of it. One example is when the URI resolution process gives an E.164 number as output, and it MUST be specified whether a new ENUM lookup should be done or not. Specifically, a registered Service MUST specify the URI scheme(s) that may be used for the Service, and, when needed, other knowledge which have to be transfered into the URI resolution process itself (LDAP DNs, tranfering of the AUS into the resulting URI, etc). 3.1.2 Naming requirement The name of a Service MUST be unique, conform to the ABNF specified in Section 2.4.2, and MUST NOT start with the facet "X-" which is reserved for exeprimental, private use. 3.1.3 Security requirement An analysis of security issues is required for for all Services registered. (This is in accordance with the basic requirements for all IETF protocols.) All descriptions of security issues must be as accurate as possible regardless of registration tree. In particular, a statement that there are "no security issues associated with this Service" must not be confused with "the security issues associates with this Service have not been assessed". There is absolutely no requirement that Services registered must be secure or completely free from risks. Nevertheless, all known security risks must be identified in the registration of a Service. The security considerations section of all registrations is subject Faltstrom & Mealling Expires August 22, 2002 [Page 7] Internet-Draft ENUM February 2002 to continuing evaluation and modification. Some of the issues that should be looked at in a security analysis of a Service are: 1. Complex Services may include provisions for directives that institute actions on a users resources. In many cases provision can be made to specify arbitrary actions in an unrestricted fashion which may then have devastating. Especially if there is a risk for a new ENUM lookup, and because of that an infinite loop in the overall resolution process of the E.164. 2. Complex Services may include provisions for directives that institute actions which, while not directly harmful, may result in disclosure of information that either facilitates a subsequent attack or else violates the users privacy in some way. 3. A Service might be targeted for applications that require some sort of security assurance but not provide the necessary security mechanisms themselves. For example, a Service could be defined for storage of confidential medical information which in turn requires an external confidentiality service. 3.1.4 Publication Requirements Proposals for Services registered must be published as RFCs. IANA will retain copies of all Service registration proposals and "publish" them as part of the ENUM Service Registration tree itself. 3.2 Registration procedure Normal IETF processes should be used for publication of the RFC which is the basis of the registration of the Service itself. 3.2.1 IANA Registration Provided that the Service has obtained approval that is necessary, and the RFC is published, IANA will register the Service and make the Service egistration available to the community in addition to the RFC publication itself. 3.2.1.1 Location of ENUM Service Registrations Service registrations will part from be published as an RFC be posted in the anonymous FTP directory "ftp://ftp.isi.edu/in- notes/iana/assignments/enum-services/". Faltstrom & Mealling Expires August 22, 2002 [Page 8] Internet-Draft ENUM February 2002 3.2.1.2 Change Control Change control of Services stay with the IETF via the RFC publication process. Especially, Service registrations may not be deleted; Services which are no longer believed appropriate for use can be declared OBSOLETE by publication of a new RFC and a change to their "intended use" field; such media types will be clearly marked in the lists published by IANA. 3.2.2 Registration Template Service Name: URI Scheme(s): Functional Specification: Security considerations: Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) Author: Any other information that the author deems interesting: Faltstrom & Mealling Expires August 22, 2002 [Page 9] Internet-Draft ENUM February 2002 4. Examples The examples below use theoretical services which have the same names as the URI schemes. That was the specification in RFC 2916, but this default specification of a Service is no longer allowed. All services need to be registered explicitly by the procedure specified in section NN. 4.1 Example 1 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:info@tele2.se!" . IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:info@tele2.se!" . This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is preferably contacted by SIP, and secondly by SMTP. In both cases, the next step in the resolution process is to use the resolution mechanism for each of the protocols, (SIP and SMTP) to know what node to contact for each. 4.2 Example 2 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:paf@swip.net!" . IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:paf@swip.net!" . IN NAPTR 102 10 "u" "tel+E2U" "!^(.*$)$!tel:\1!" . Note that the preferred method is to use the SIP protocol. The URI is resolved as described in RFC 2543 [6]. In the case of the "tel" URI scheme [7], a replacement "\1" is used. The rest of the resolution of the routing is done as described above. 4.3 Example 3 $ORIGIN 6.4.e164.arpa. * IN NAPTR 100 10 "u" "ldap+E2U" "!^+46(.*)$!ldap://ldap.se/cn=\1!" . Faltstrom & Mealling Expires August 22, 2002 [Page 10] Internet-Draft ENUM February 2002 We see in this example that information about all E.164 numbers in the 46 countrycode (for Sweden) exists in an LDAP server, and the search to do is specified by the LDAP URI [8]. Faltstrom & Mealling Expires August 22, 2002 [Page 11] Internet-Draft ENUM February 2002 5. IANA Considerations This memo requests that the IANA delegate the E164.ARPA domain following instructions to be provided by the IAB. Names within this zone are to be delegated to parties according to the ITU recommendation E.164. The names allocated should be hierarchic in accordance with ITU Recommendation E.164, and the codes should assigned in accordance with that Recommendation. Delegations in the zone e164.arpa (not delegations in delegated domains of e164.arpa) should be done after Expert Review, and the IESG will appoint a designated expert. IANA is to create a registry for ENUM Services as specified in Section 3. Whenever a new ENUM Service is registered by the RFC process in the IETF, IANA is at the time of publication of the RFC to register the Service and add a pointer to the RFC itself. Faltstrom & Mealling Expires August 22, 2002 [Page 12] Internet-Draft ENUM February 2002 6. Security Considerations As this system is built on top of DNS, one can not be sure that the information one get back from DNS is more secure than any DNS query. To solve that, the use of DNSSEC [9] for securing and verifying zones is to be recommended. The caching in DNS can make the propagation time for a change take the same amount of time as the time to live for the NAPTR records in the zone that is changed. The use of this in an environment where IP-addresses are for hire (for example, when using DHCP [11]) must therefore be done very carefully. There are a number of countries (and other numbering environments) in which there are multiple providers of call routing and number/name- translation services. In these areas, any system that permits users, or putative agents for users, to change routing or supplier information may provide incentives for changes that are actually unauthorized (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes. A large amount of Security Issues have to do with the resolution process itself, and use of the URI's produced by the DDDS mechanism. Those have to be specified in the registration of the ENUM Service used, as specified in Section 3.1.3. Faltstrom & Mealling Expires August 22, 2002 [Page 13] Internet-Draft ENUM February 2002 7. Acknowledgments Support and ideas leading to RFC 2916 have come from people at Ericsson, Bjorn Larsson and the group which implemented this scheme in their lab to see that it worked. Input has also come from ITU-T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and Service Definition), the ENUM working group in the IETF, John Klensin and Leif Sunnegardh. This update of that RFC is created with input from (in alphabetical order): David Conrad, James Yu, Jim Reid, Joakim Stralmark, Randy Bush and Richard Hill. Faltstrom & Mealling Expires August 22, 2002 [Page 14] Internet-Draft ENUM February 2002 References [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf-urn- ddds-toc-02.txt (work in progress), February 2002. [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-06.txt (work in progress), February 2002. [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- database-08.txt (work in progress), February 2002. [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The URI Resolution Application", RFC YYYY, draft-ietf-urn- uri-res-ddds-06.txt (work in progress), February 2002. [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf-urn- net-procedures-10.txt (work in progress), February 2002. [6] Mealling, M., "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999. [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [8] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", RFC 2717, BCP 35, November 1999. Authors' Addresses Patrik Faltstrom Cisco Systems Inc 170 W Tasman Drive SJ-13/2 San Jose, CA 95134 USA EMail: paf@cisco.com URI: http://www.cisco.com Faltstrom & Mealling Expires August 22, 2002 [Page 15] Internet-Draft ENUM February 2002 Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US EMail: michael@neonym.net URI: http://www.verisignlabs.com Faltstrom & Mealling Expires August 22, 2002 [Page 16] Internet-Draft ENUM February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Faltstrom & Mealling Expires August 22, 2002 [Page 17] _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 15:48:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03537 for ; Thu, 21 Feb 2002 15:48:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25152 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 15:47:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24782; Thu, 21 Feb 2002 15:39:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24754 for ; Thu, 21 Feb 2002 15:39:09 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03034 for ; Thu, 21 Feb 2002 15:39:00 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA12453 for ; Thu, 21 Feb 2002 21:38:31 +0100 (MET) Date: Thu, 21 Feb 2002 21:38:24 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org Subject: Re: [Enum] 2916bis Message-ID: <7731583.1014327504@localhost> In-Reply-To: <7698459.1014326952@localhost> References: <7698459.1014326952@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA24755 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit --On 2002-02-21 21.29 +0100 Patrik F�ltstr�m wrote: > IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:info@tele2.se!" . > IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:info@tele2.se!" . > IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:paf@swip.net!" . > IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:paf@swip.net!" . > IN NAPTR 102 10 "u" "tel+E2U" "!^(.*$)$!tel:\1!" . Ok, I see myself that the examples are wrong. I forgot to change them. The correct ones should be: IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:info@tele2.se!" . IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:info@tele2.se!" . IN NAPTR 10 10 "u" "E2U+sip" "!^.*$!sip:paf@swip.net!" . IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:paf@swip.net!" . IN NAPTR 102 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 21 16:19:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04653 for ; Thu, 21 Feb 2002 16:19:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26822 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 16:19:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26510; Thu, 21 Feb 2002 16:11:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26479 for ; Thu, 21 Feb 2002 16:11:00 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04322 for ; Thu, 21 Feb 2002 16:10:55 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id NAA03026; Thu, 21 Feb 2002 13:07:38 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Feb 2002 13:07:38 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B014B100A@opwinex01.corp.illuminet.com> From: Kevin McCandless To: "'Richard Shockey'" , Lawrence Conroy , Eric Brunner-Williams in Portland Maine , "Stastny, Richard" Cc: "'Eric Brunner-Williams in Portland Maine'" , "'Christian Huitema'" , enum@ietf.org Subject: RE: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) Date: Thu, 21 Feb 2002 13:07:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Not to agree or disagree with any previous comments here are my thoughts. If a call is made from the PSTN to a VoIP network in which the VoIP customers only have URL addresses; then a database dip will need to be done to translate the 10 digit number dialed into a URL for the call to be completed. Whether this database will be ENUM or a priority database operated by the VoIP carrier is a whole other issue. Yes, my favorite statement applies here; 'it is a market place decision'. Thanks for reading, Kevin......... -----Original Message----- From: Richard Shockey [mailto:rich.shockey@NeuStar.com] Sent: Thursday, February 21, 2002 12:16 PM To: Lawrence Conroy; Eric Brunner-Williams in Portland Maine; Stastny, Richard Cc: 'Eric Brunner-Williams in Portland Maine'; 'Christian Huitema'; enum@ietf.org Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) > >To which I add: > actually, 3GPP include an allusion to ENUM in the IMS documents > (TS23.228 - >a word doc, I'm afraid, so I'll let you retrieve it from ftp.3gpp.org). > >This is also in the call setup procedures and is not done by the Mobile. I've been scratching my head over this thread..... so can some one define what is "call setup procedures" ??? Is there some common definition here? I've always looked at ENUM as a globally authoritive database that can convert a name (E.164 number) into a list of possible services. ENUM could be part of a set of databases or tables ( local or otherwise) that can assist a network element in making a decision on how to potentially terminate (route or switch) a particular media stream. How and when a look up occurs could be nearly anywhere depending on the network configuration and the pathway by which the media stream originates. >Thus I tend to agree with Chip; whether or not ENUM is initiated within >the call setup sequence is an applicability issue, not one for 2916. > >BTW (mindful that this is an IETF list, so apologies for the inappropriate >content): >(i) it's IP traffic so it's covered by CALEA (or RIPA over here), right? >(ii) do you really expect and answer to "how do you do it if it's >decentralised" ? > >all the best, > Lawrence >-- >lwc@roke.co.uk: +44 1794 833666::: > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, 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 daemon@optimus.ietf.org Thu Feb 21 17:19:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05983 for ; Thu, 21 Feb 2002 17:19:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA29931 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 17:19:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29658; Thu, 21 Feb 2002 17:09:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29631 for ; Thu, 21 Feb 2002 17:09:50 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05873 for ; Thu, 21 Feb 2002 17:09:41 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1LM9CE22927; Thu, 21 Feb 2002 14:09:13 -0800 (PST) Received: from CHSHARP-W2K1.cisco.com (rtp-vpn2-105.cisco.com [10.82.240.105]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA08649; Thu, 21 Feb 2002 14:09:09 -0800 (PST) Message-Id: <4.3.2.7.2.20020221170301.04ab2c10@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Feb 2002 17:08:37 -0500 To: Richard Shockey From: Chip Sharp Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) Cc: enum@ietf.org In-Reply-To: <5.1.0.14.2.20020221120158.0409cd98@popd.ix.netcom.com> References: <200202211550.g1LFo1182952@nic-naa.net> <200202211550.g1LFo1182952@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org http://www.wordfocus.com/word-act-blindmen.html ENUM=elephant I've always felt ENUM was the set of procedures and algorithms defined in RFC2916 that can be used for a multitude of applications & services. :-) Chip At 01:16 PM 2/21/2002, Richard Shockey wrote: >>To which I add: >> actually, 3GPP include an allusion to ENUM in the IMS documents (TS23.228 - >>a word doc, I'm afraid, so I'll let you retrieve it from ftp.3gpp.org). >> >>This is also in the call setup procedures and is not done by the Mobile. > >I've been scratching my head over this thread..... so can some one define what is "call setup procedures" ??? Is there some common definition here? > >I've always looked at ENUM as a globally authoritive database that can convert a name (E.164 number) into a list of possible services. ENUM could be part of a set of databases or tables ( local or otherwise) that can assist a network element in making a decision on how to potentially terminate (route or switch) a particular media stream. > >How and when a look up occurs could be nearly anywhere depending on the network configuration and the pathway by which the media stream originates. > >>Thus I tend to agree with Chip; whether or not ENUM is initiated within >>the call setup sequence is an applicability issue, not one for 2916. >> >>BTW (mindful that this is an IETF list, so apologies for the inappropriate content): >>(i) it's IP traffic so it's covered by CALEA (or RIPA over here), right? >>(ii) do you really expect and answer to "how do you do it if it's decentralised" ? >> >>all the best, >> Lawrence >>-- >>lwc@roke.co.uk: +44 1794 833666::: >> >>_______________________________________________ >>enum mailing list >>enum@ietf.org >>https://www1.ietf.org/mailman/listinfo/enum > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Senior Manager, Strategic Technology Initiatives >NeuStar Inc. >45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 >1120 Vermont Ave NW Suite 400 Washington DC 20005 >Voice +1 571.434.5651 Cell : +1 314.503.0640, 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 daemon@ns.ietf.org Thu Feb 21 20:10:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08449 for ; Thu, 21 Feb 2002 20:10:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA07105 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 20:10:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06187; Thu, 21 Feb 2002 19:57:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06157 for ; Thu, 21 Feb 2002 19:57:31 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08300 for ; Thu, 21 Feb 2002 19:57:28 -0500 (EST) Received: from [193.118.192.111] (HELO [158.152.16.98]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062720 for ; Fri, 22 Feb 2002 00:57:28 +0000 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Fri, 22 Feb 2002 00:57:20 +0000 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] 2916bis initial review Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Folks, as requested by our Learned authors, herewith some initial comments on a brief readthrough of 2916bis. First, a plea - PLEASE choose something more intuitive that RFC VVVV, RFC WWWW, RFC XXXX, RFC YYYY, RFC ZZZZ. This does not make things easier to read (Whilst reading through the cycle, I keep finding myself pondering "Is YYYY the algorithn one, or is it the TOC, or the Database one?".) line 145: s/specify/specifies/ lines 156-159 - client can choose its own ordering. Is this choice restricted to being based on service fields and the resulting scheme of the URI (assuming that it's a terminal :)? lines 187-191 - please make up your minds - either the initial Key has a leading '+' sign, or it doesn't. The 1WNR converts from AUS (with leading '+') to a Key. In list postings, I believe that Michael agreed that the Key does NOT have this, so the 1ENR will NOT be null - it has to remove the leading '+' character. Thus AUS .NE. Key. If this is changed (as on the list), then line 208 loses the "except for the +", lines 212-214 go, and lines 215, 217 and 226 have the initial number reduced. (and the text of lines 187-188 changes, of course). If not, then please add text to explain why a Key needs the initial '+' character. lines 229-230 - this *only* happens if the result of NAPTR processing is non-terminal. Thus this is incorrect as stated. (lose the "which produces new keys in the form of domain names" - suggest you add "from the DNS" instead). I'm surprised at tone of the statement on lines 232-238 - this does not have the health warning (i.e. it's another IPV6/PKI/... and so might happen some time before I retire) that appears in the D3S DNS draft. line 247 - "Database" - I think that this should be each record, or each NAPTR - it isn't Database. line 259-260 - This sentence needs work, as nothing exists at a Key; it may exist at a record indexed by a key, or returned by a subsequent query into the database indexed by a Key, but that is not what's stated here. In the D3S Algorithm draft, the term "non-terminal rule" is used. Why not use it here? I like the rename from (protocol & RS) to enumservice (even though it's slightly inconvenient for those writing specs). However, ... line 271 - still has "protocol and rs" -> "enumservice". lines 307-308 - Brave! Henning may well complain on this (in the SIP groups he has definite views that the use of "X-" is harmful :). (also lines 366-367). line 360 - s/have/will have/ Security issues - lines 399-415 I recognise the template; however, one risk that is common to many of the services "on offer" will be that a caller may be duped into initiating an action that costs lots of money. Not exactly privacy, but it sure is an attack. This is nearly covered in point 2, but perhaps that could be expanded without mentioning the "M" word directly. line 455 - Question: can a Service be declared Historic? In addition to the changes to the examples mentioned on the list... line 551 should be: * IN NAPTR 100 10 "u" "E2U+ldap" "!^+46(.*)$!ldap://ldap.se/cn=\1!" . line 698 - s/URI's/URIs/ The suspicious amongst us may conclude that the whole purpose of D3S and this update (apart from frying a few surplus brain cells) is highlighted on lines 546-564. You might think that, but I couldn't possibly... -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Feb 21 20:57:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08459 for ; Thu, 21 Feb 2002 20:10:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA07119 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 20:10:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06467; Thu, 21 Feb 2002 20:01:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06372 for ; Thu, 21 Feb 2002 20:01:49 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08347 for ; Thu, 21 Feb 2002 20:00:14 -0500 (EST) Received: from [193.118.192.111] (HELO [158.152.16.98]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062721 for ; Fri, 22 Feb 2002 01:00:14 +0000 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Fri, 22 Feb 2002 00:57:20 +0000 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] 2916bis initial review Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Folks, as requested by our Learned authors, herewith some initial comments on a brief readthrough of 2916bis. First, a plea - PLEASE choose something more intuitive that RFC VVVV, RFC WWWW, RFC XXXX, RFC YYYY, RFC ZZZZ. This does not make things easier to read (Whilst reading through the cycle, I keep finding myself pondering "Is YYYY the algorithn one, or is it the TOC, or the Database one?".) line 145: s/specify/specifies/ lines 156-159 - client can choose its own ordering. Is this choice restricted to being based on service fields and the resulting scheme of the URI (assuming that it's a terminal :)? lines 187-191 - please make up your minds - either the initial Key has a leading '+' sign, or it doesn't. The 1WNR converts from AUS (with leading '+') to a Key. In list postings, I believe that Michael agreed that the Key does NOT have this, so the 1ENR will NOT be null - it has to remove the leading '+' character. Thus AUS .NE. Key. If this is changed (as on the list), then line 208 loses the "except for the +", lines 212-214 go, and lines 215, 217 and 226 have the initial number reduced. (and the text of lines 187-188 changes, of course). If not, then please add text to explain why a Key needs the initial '+' character. lines 229-230 - this *only* happens if the result of NAPTR processing is non-terminal. Thus this is incorrect as stated. (lose the "which produces new keys in the form of domain names" - suggest you add "from the DNS" instead). I'm surprised at tone of the statement on lines 232-238 - this does not have the health warning (i.e. it's another IPV6/PKI/... and so might happen some time before I retire) that appears in the D3S DNS draft. line 247 - "Database" - I think that this should be each record, or each NAPTR - it isn't Database. line 259-260 - This sentence needs work, as nothing exists at a Key; it may exist at a record indexed by a key, or returned by a subsequent query into the database indexed by a Key, but that is not what's stated here. In the D3S Algorithm draft, the term "non-terminal rule" is used. Why not use it here? I like the rename from (protocol & RS) to enumservice (even though it's slightly inconvenient for those writing specs). However, ... line 271 - still has "protocol and rs" -> "enumservice". lines 307-308 - Brave! Henning may well complain on this (in the SIP groups he has definite views that the use of "X-" is harmful :). (also lines 366-367). line 360 - s/have/will have/ Security issues - lines 399-415 I recognise the template; however, one risk that is common to many of the services "on offer" will be that a caller may be duped into initiating an action that costs lots of money. Not exactly privacy, but it sure is an attack. This is nearly covered in point 2, but perhaps that could be expanded without mentioning the "M" word directly. line 455 - Question: can a Service be declared Historic? In addition to the changes to the examples mentioned on the list... line 551 should be: * IN NAPTR 100 10 "u" "E2U+ldap" "!^+46(.*)$!ldap://ldap.se/cn=\1!" . line 698 - s/URI's/URIs/ The suspicious amongst us may conclude that the whole purpose of D3S and this update (apart from frying a few surplus brain cells) is highlighted on lines 546-564. You might think that, but I couldn't possibly... -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Feb 21 21:10:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09298 for ; Thu, 21 Feb 2002 21:10:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA09934 for enum-archive@odin.ietf.org; Thu, 21 Feb 2002 21:10:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09632; Thu, 21 Feb 2002 21:01:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09587 for ; Thu, 21 Feb 2002 21:01:22 -0500 (EST) Received: from 192.168.181.1 (mcns160.docsis207.scvmaxonline.com.sg [202.156.207.160]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09160 for ; Thu, 21 Feb 2002 21:01:18 -0500 (EST) Message-ID: <002101c1bb44$afff5100$0c64a8c0@maynardibm> From: "Maynard Kang" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , References: <7698459.1014326952@localhost> Subject: Re: [Enum] 2916bis Date: Fri, 22 Feb 2002 10:00:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-GCMulti: 1 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Hi Patrick et al, > (1) The service field in the NAPTR is now the following > > service_field = [ "E2U" 1*("+" enumservice)] > > This is _NOT_ backward compatible. Reason for this is that > one could register for example sipvoice, sipgaming and > sipimpp and then have the service field which is > > E2U+sipvoice+sipgaming+sipimpp > Just one minor issue: URI is denoted by "I" and not "U", according to the [RFC 2483] rs convention. If we want to keep to this convention, then E.164-to-URI should be "E2I" and not "E2U". Other rs using an E164 number as the operand can then be defined according to the same convention (e.g. E2C, E2L, E2R). If we don't really need to keep to this convention then I guess the point is moot. regards, maynard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 02:25:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23598 for ; Fri, 22 Feb 2002 02:25:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01345 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 02:25:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00848; Fri, 22 Feb 2002 02:15:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00819 for ; Fri, 22 Feb 2002 02:15:20 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23409 for ; Fri, 22 Feb 2002 02:15:13 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA09091 for ; Fri, 22 Feb 2002 08:14:43 +0100 (MET) Date: Fri, 22 Feb 2002 07:41:57 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org Message-ID: <9904453.1014363717@localhost> In-Reply-To: <7698459.1014326952@localhost> References: <7698459.1014326952@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Enum] Registration of enumservices Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit As you now understand the view I have collected from people is that we need separate documents which is the actual registration of enumservices. To "test" 2916bis, and also get some more documents rolling, I would like people trying to write such I-D's as soon as possible. That is for example what I personally belive the sipping draft about use of ENUM and SIP should turn into. I have also heard rumors of someone working on one which describes some enumservice which use the tel URI. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 02:25:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23621 for ; Fri, 22 Feb 2002 02:25:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01367 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 02:25:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00811; Fri, 22 Feb 2002 02:15:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00780 for ; Fri, 22 Feb 2002 02:15:13 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23407 for ; Fri, 22 Feb 2002 02:15:10 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA09078; Fri, 22 Feb 2002 08:14:40 +0100 (MET) Date: Fri, 22 Feb 2002 07:36:57 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] 2916bis initial review Message-ID: <9886436.1014363417@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-22 00.57 +0000 Lawrence Conroy wrote: > > First, a plea - PLEASE choose something more intuitive that RFC VVVV, > RFC WWWW, RFC XXXX, RFC YYYY, RFC ZZZZ. > This does not make things easier to read (Whilst reading through the > cycle, I keep finding myself pondering "Is YYYY the algorithn one, or is > it the TOC, or the Database one?".) > Problem is that we don't know the RFC numbers yet. The DDDS documents will be done 2 weeks from today (my guess) and when they have numbers, they will fall into place. The other number is the number this document will get. This is a normal way of writing in I-D's. What should be there is a reference at the first occation to the reference list where the full title is. If that is missing somewhere, it should be corrected. When the document is turning into an RFC, these references / writings are resolved by the RFC Editor, so they will have real numbers when published. > > line 145: s/specify/specifies/ > Ok. > > lines 156-159 - client can choose its own ordering. Is this choice > restricted to being based on service fields and the resulting scheme of > the URI (assuming that it's a terminal :)? > Maybe a combination of URI scheme and destination. But, the important thing is that the client _can_ choose. The choice of URI scheme or service field can in turn be different depending on available resources locally? I.e. not only statically configured. Say that you in the U.S. get two NAPTR RR for my phone number. One has higher priority and is a PSTN/voice thing, and the other with lower priority is SIP/voice. The text makes it _possible_ for you to choose the SIP/voice NAPTR even though the other has higher priority, and that because the PSTN/voice selection would impose higher costs for you. I.e. it is still the case that for many ways of communicating, it is the originator which pays. So, for me personally it is important that both the receiver of the communication and the originator can "express" their policy. > > lines 187-191 - please make up your minds - either the initial Key > has a leading '+' sign, or it doesn't. The 1WNR converts from AUS > (with leading '+') to a Key. In list postings, I believe that Michael > agreed that the Key does NOT have this, so the 1ENR will NOT be null > - it has to remove the leading '+' character. Thus AUS .NE. Key. > > If this is changed (as on the list), then line 208 loses the "except for > the +", lines 212-214 go, and lines 215, 217 and 226 have the initial > number reduced. (and the text of lines 187-188 changes, of course). > > If not, then please add text to explain why a Key needs the initial '+' > character. > The + should be there as part of the input to the NAPTR regexp matching, but is not part of the domain name. This is Michaels part of the draft, and he has to see that the WNR, AUS etc ends up being correct. Explanation why the leading + is there is already in section 1.2. Is that enough for you, or do you want a pointer from the WNR section to 1.2? > > lines 229-230 - this *only* happens if the result of NAPTR processing is > non-terminal. Thus this is incorrect as stated. (lose the "which produces > new keys in the form of domain names" - suggest you add "from the DNS" > instead). Good catch. Thanks! > > I'm surprised at tone of the statement on lines 232-238 - this does not > have the health warning (i.e. it's another IPV6/PKI/... and so might > happen some time before I retire) that appears in the D3S DNS draft. > I think this part is coming from some other DDDS specification Michael has written. I.e. to me it seems like a general DDDS document spec. It should be tuned more specifically to E2U. Michael? > > line 247 - "Database" - I think that this should be each record, or each > NAPTR - it isn't Database. > Well, "Database" is here a DDDS terminology thing. But I guess it can be changed so people understand the sentence. I have no problem with this. > > line 259-260 - This sentence needs work, as nothing exists at a Key; it > may exist at a record indexed by a key, or returned by a subsequent > query into the database indexed by a Key, but that is not what's stated > here. In the D3S Algorithm draft, the term "non-terminal rule" is used. > Why not use it here? > This is for Michael. > > I like the rename from (protocol & RS) to enumservice (even though it's > slightly inconvenient for those writing specs). However, ... > line 271 - still has "protocol and rs" -> "enumservice". > I don't know myself if we _really_ should change the grammar from what it is in the DDDS documents. Michael suggested it, and it is crystal clear how this works. But, if you are used to DDDS things, you might be confused, maybe? One alternative is to use the same grammar as the DDDS documents, but then have constraints for each of the values. I personally still like this way of describing things, and I agree with you that line 271 should be changed. > > lines 307-308 - Brave! Henning may well complain on this (in the SIP > groups he has definite views that the use of "X-" is harmful :). > (also lines 366-367). > :-) Sure, but what does he use before something is really registered? Note that we force the enumservices to exist as RFC's. When creating an RFC, I really like writing code, and the question is what I use during that process. I do _NOT_ like what some people do (I don't know if Henning like this more ;-) and that is to "grab" some random string they think is free. Problem is that if people don't get the ability to just picking something, they will start using something (like "sipvoice"). They write the RFC, and in the RFC say they want that string. Now, IANA or IESG say "no, but you can get "foobar" instead. It has then happened too many times that we in IESG get back angry email saying "but, this is already deployed, you can not change the string for us _now_". The response is some polite version of "Watch us". > > line 360 - s/have/will have/ > Thanks. > > Security issues - lines 399-415 > I recognise the template; however, one risk that is common to many of > the services "on offer" will be that a caller may be duped into > initiating an action that costs lots of money. Not exactly privacy, but > it sure is an attack. This is nearly covered in point 2, but perhaps > that could be expanded without mentioning the "M" word directly. > If you suggest text, I will cut and paste. I think we in this section should list as much as possible. _ANY_ likely issue should be listed. > > line 455 - Question: can a Service be declared Historic? > The specification (the RFC) can become historic, but the enumservice it defines ends up being OBSOLETE. The possible "states" are normal IANA ones. Look at the registration mechanism for content-types for example. RFC 2048. > > In addition to the changes to the examples mentioned on the list... > line 551 should be: > * IN NAPTR 100 10 "u" "E2U+ldap" > "!^+46(.*)$!ldap://ldap.se/cn=\1!" . Yes, I need to look at these in detail. Maybe someone can send in more fun examples? These are pretty boring. Or? > > line 698 - s/URI's/URIs/ > Ok. > > The suspicious amongst us may conclude that the whole purpose of D3S and > this update (apart from frying a few surplus brain cells) is highlighted > on lines 546-564. You might think that, but I couldn't possibly... > Well, the LDAP example existed in the previous version? The changes is a more crisp binding to the DDDS architecture and need for registration mechanism of enumservices. Really needed things from my point of view. It might be that I don't understand... paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 03:12:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23596 for ; Fri, 22 Feb 2002 02:25:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01346 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 02:25:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00889; Fri, 22 Feb 2002 02:15:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00854 for ; Fri, 22 Feb 2002 02:15:23 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23412 for ; Fri, 22 Feb 2002 02:15:21 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA09083; Fri, 22 Feb 2002 08:14:42 +0100 (MET) Date: Fri, 22 Feb 2002 07:39:17 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Maynard Kang , enum@ietf.org Subject: Re: [Enum] 2916bis Message-ID: <9894809.1014363557@localhost> In-Reply-To: <002101c1bb44$afff5100$0c64a8c0@maynardibm> References: <7698459.1014326952@localhost> <002101c1bb44$afff5100$0c64a8c0@maynardibm> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-22 10.00 +0800 Maynard Kang wrote: > URI is denoted by "I" and not "U", according to the [RFC 2483] rs > convention. > If we want to keep to this convention, then E.164-to-URI should be "E2I" > and not > "E2U". > > Other rs using an E164 number as the operand can then be defined > according to the same convention (e.g. E2C, E2L, E2R). Interesting. I have personally been working a lot with RFC 2483 and others, but this is the first time I hear someone binding the NAPTR service field to that RFC. Hmmm... Originally E2U was picked just because the string "E.164" start with 'E' and "URI" start with 'U'. :-) paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 03:29:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24362 for ; Fri, 22 Feb 2002 03:29:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA04459 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 03:29:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04015; Fri, 22 Feb 2002 03:19:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03984 for ; Fri, 22 Feb 2002 03:19:30 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24173 for ; Fri, 22 Feb 2002 03:19:27 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA18229; Fri, 22 Feb 2002 09:18:50 +0100 (MET) Date: Fri, 22 Feb 2002 09:12:34 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , Michael Mealling cc: enum@ietf.org Subject: Re: [Enum] NAPTR RS sub-field field and why it's there Message-ID: <10230684.1014369154@localhost> In-Reply-To: References: <20020221085152.L26811@bailey.dscga.com> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-21 16.30 +0000 Lawrence Conroy wrote: > Whilst you're at this, why not re-consider the names of these sub-fields. We now only talk about "enumservice". paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 03:42:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24550 for ; Fri, 22 Feb 2002 03:42:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA05530 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 03:42:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05139; Fri, 22 Feb 2002 03:33:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05032 for ; Fri, 22 Feb 2002 03:32:55 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24430 for ; Fri, 22 Feb 2002 03:32:52 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA20522; Fri, 22 Feb 2002 09:32:14 +0100 (MET) Date: Fri, 22 Feb 2002 09:30:04 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Richard Shockey , Lawrence Conroy , "Yu, James" cc: enum@ietf.org, richard.stastny@oefeg.at Subject: RE: [Enum] Re. 2916bis Message-ID: <10293631.1014370204@localhost> In-Reply-To: <5.1.0.14.2.20020221112038.041eaae0@popd.ix.netcom.com> References: <23309E398D84D5119D0F00306E075139ECEC5C@dc02.npac.com> <23309E398D84D5119D0F00306E075139ECEC5C@dc02.npac.com> <5.1.0.14.2.20020221112038.041eaae0@popd.ix.netcom.com> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-21 11.23 -0500 Richard Shockey wrote: > Yes but we have previously had discussions (pittsburg i recall) that the > use of CNAME and DNAME are very dangerous if not configured correctly and > as we know the vast majority of DNS errors are in configuration. Let me phrase this differently: ENUM "just" use the DNS for storage of data. Because of this, the resolver which looks up the NAPTR resource records have to be conformant with relevant DNS related RFC's -- which might be updated over time. We already know the DNS people talk about EDNS0, DNSSEC, IPv6 transport, TKEY, Dynamic Updates, packet size adjustments etc etc. The whole key of (re-)using DNS is that we in this wg don't have to worry about it. That we talked about CNAME and DNAME was just because in informal communication with DNS people we have understood that _they_ recommend people _not_ to use DNAME at all, and CNAME only when the "link" crosses administrative boundaries. But, once again, this is a DNS issue, and should be discussed in the DNSOP wg in the IETF. I.e. if you are interested and maybe even worried about DNS operations, you should go to _that_ working group. Here we only use DNS as a storage location and we take for granted that the DNSOP and DNSEXT working groups will do their job. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 03:44:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24582 for ; Fri, 22 Feb 2002 03:44:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA05622 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 03:44:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05257; Fri, 22 Feb 2002 03:34:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05221 for ; Fri, 22 Feb 2002 03:34:36 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24452 for ; Fri, 22 Feb 2002 03:34:33 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA20508; Fri, 22 Feb 2002 09:32:11 +0100 (MET) Date: Fri, 22 Feb 2002 09:25:35 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Eric Brunner-Williams in Portland Maine , "Stastny, Richard" cc: "'Eric Brunner-Williams in Portland Maine'" , "'Christian Huitema'" , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) Message-ID: <10277519.1014369935@localhost> In-Reply-To: <200202211550.g1LFo1182952@nic-naa.net> References: <200202211550.g1LFo1182952@nic-naa.net> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-21 10.50 -0500 Eric Brunner-Williams in Portland Maine wrote: > The Jim is our own Jim Reid, neh? Who was the "China" explaining to he and > Patrik? I guess it is Jim Reid. The issues China has with e164.arpa has nothing to do with ENUM, but other more political things. I spent quite some time with them in Geneva, and the text passed _can_ (and I think is) blown to proportions which is not of the same scale as the actual discussions. China supported the use of e164.arpa and the instructions to TSB, but, wanted an examination of locations of the root and arpa nameservers (which is an RSAC issue). I.e. they wanted more data and experiments on impact on doing ENUM during call setup, and I think that is fair. "China" included people which sent in the request to RIPE NCC for delegation of their E.164 CC, so there is support. Much more than what readers of this list might think. Can we go back to discuss 2916bis and relevant documents please? paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 04:47:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25310 for ; Fri, 22 Feb 2002 04:47:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09070 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 04:47:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08301; Fri, 22 Feb 2002 04:36:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08268 for ; Fri, 22 Feb 2002 04:36:31 -0500 (EST) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25117; Fri, 22 Feb 2002 04:36:17 -0500 (EST) Date: Fri, 22 Feb 2002 10:36:09 +0100 To: internet-drafts@ietf.org cc: ietf-fax@imc.org, discuss@apps.ietf.org, enum@ietf.org, ietf@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="5692-1103527590-1014374169=:559949238" From: Claudio Allocchio Subject: [Enum] DRAFT-ALLOCCHIO-GSTN-02.TXT Updated version Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --5692-1103527590-1014374169=:559949238 Content-Type: TEXT/PLAIN; charset=US-ASCII Hallo, here is the updated version of DRAFT-ALLOCCHIO-GSTN-02.TXT, which includes, as the only difference from the previous one, an "implementer's note" regarding 'pause' and 'tonewait' which was suggested as helpful. As mentioned in the first release of the draft, "the intention for this document is to provide a unique syntax for Dial Sequences, including expecially phone numbers as a subset. The definitions contained in the draft actually come from existing Draft Standard and Proposed Standard specifications, but were collected here to provide a quick, easy and unique reference document for anybody needing this particualr encoding. The original idea comes from the Application Area Directors, and I made the collection and edited the I-D." I kindly invite you to provide me your comments and suggestions! Thank you all, and regards! Claudio Allocchio ietf fax wg co-chair --5692-1103527590-1014374169=:559949238 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="DRAFT-ALLOCCHIO-GSTN-02.TXT" Content-ID: Content-Description: Content-Transfer-Encoding: BASE64 TmV0d29yayBXb3JraW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBDLiBBbGxvY2NoaW8NCkdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBH QVJSLUl0YWx5DQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAwMg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV4 cGlyZXM6ICAgQXVndXN0IDIwMDINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRmlsZTogZHJhZnQtYWxsb2NjaGlvLWdzdG4tMDIu dHh0DQoNCg0KDQogICAgVGV4dCBzdHJpbmcgbm90YXRpb24gZm9yIERpYWwg U2VxdWVuY2VzIGFuZCBHU1ROIC8gRS4xNjQgYWRkcmVzc2VzDQoNCg0KU3Rh dHVzIG9mIHRoaXMgTWVtbw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIElu dGVybmV0IERyYWZ0IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGgN CiAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4N Cg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElF VEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3Rl IHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4NCg0KICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiBzaXgNCiAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQs IHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzDQog ICBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIElu dGVybmV0LURyYWZ0cyBhcyANCiAgIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0 byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i DQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNh biBiZSBhY2Nlc3NlZCBhdA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2lldGYvMWlkLWFic3RyYWN0cy50eHQNCg0KICAgVGhlIGxpc3Qgb2YgSW50 ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3Nl ZCBhdA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhl IEludGVybmV0IFNvY2lldHkgKDIwMDEpLiAgQWxsIFJpZ2h0cyBSZXNlcnZl ZC4NCg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIG1lbW8gZGVzY3JpYmVzIHRo ZSBmdWxsIHNldCBvZiBub3RhdGlvbnMgbmVlZGVkIHRvIHJlcHJlc2VudA0K ICAgaW4gYSB0ZXh0IHN0cmluZyBhIERpYWwgU2VxdWVuY2UuIEEgRGlhbCBT ZXF1ZW5jZSBpcyBub3JtYWxseQ0KICAgY29tcG9zZWQgYnkgRHVhbCBUb25l IE11bHRpIEZyZXF1ZW5jeSAoRFRNRikgZWxlbWVudHMgWzFdIHBsdXMgDQog ICBzZXBhcmF0b3JzIGFuZCB0aGUgYWRkaXRpb25hbCAiYWN0aW9ucyIgKHN1 Y2ggYXMgIndhaXQgZm9yDQogICBkaWFsdG9uZSIsICJwYXVzZSBmb3IgTiBz ZWNzIiwgZXRjLikgd2hpY2ggY291bGQgYmUgbmVlZGVkIHRvIA0KICAgc3Vj Y2Vzc2Z1bGx5IGVzdGFibGlzaCB0aGUgY29ubmVjdGlvbiB3aXRoIHRoZSB0 YXJnZXQgc2VydmljZToNCiAgIHRoaXMgaW5jbHVkZXMgdGhlIGNhc2VzIHdo ZXJlIHN1YmFkZHJlc3NlcyBvciBEVE1GIG1lbnUgbmF2aWdhdGlvbiANCiAg IGFwcGx5LiBHbG9iYWwgU3dpdGNoZWQgVGVsZXBob25lIE51bWJlcnMgKEdT VE4pIC8gRS4xNjQgYWRkcmVzc2VzIA0KICAgKGNvbW1vbmx5IGNhbGxlZCAi dGVsZXBob25lIG51bWJlcnMiKSBbMl0gYXJlIGEgc3Vic2V0IG9mIGEgRGlh bCANCiAgIFNlcXVlbmNlLCBhbmQgdGh1cyB1c2UgdGhlIHNhbWUgc2V0IG9m IG5vdGF0aW9ucy4NCg0KICAgVGhpcyBub3RhdGlvbiBNVVNUIGJlIHVzZWQg aW4gYWxsIHNwZWNpZmljYXRpb25zIG5lZWRpbmcgYSB0ZXh0DQogICBzdHJp bmcgcmVwcmVzZW50YXRpb24gb2YgYSBEaWFsIFNlcXVlbmNlIChpbmNsdWRp bmcgR1NUTiAvIEUuMTY0DQogICBhZGRyZXNzZXMpLg0KDQoNCjEuIEludHJv ZHVjdGlvbg0KDQogICBTaW5jZSB0aGUgdmVyeSBmaXJzdCBkZXZpY2VzIGlu dGVyYWN0aW5nIHdpdGggR1NUTiBzZXJ2aWNlcyBhcHBlYXJlZCwgDQogICBh IG5lZWQgZm9yIGEgdW5pcXVlIHRleHQgc3RyaW5nIHJlcHJlc2VudGF0aW9u IG9mIHRlbGVwaG9uZSBudW1iZXJzLCANCiAgIGFuZCBtb3JlIGdlbmVyYWxs eSBEVE1GIHNlcXVlbmNlcyBhbmQgYWN0aW9ucywgd2FzIGZvcnNlZW4uDQoN CiAgIFRoaXMgbWVtbyBkZXNjcmliZXMgdGhlIGZ1bGwgdGV4dCBzdHJpbmcg cmVwcmVzZW50YXRpb24gbWV0aG9kLiBUaGUNCiAgIG1haW4gc2NvcGUgaXMg dGh1cyB0byBwcm92aWRlIGEgdW5pcXVlIGFuZCBjb21wbGV0ZSByZWZlcmVu Y2UgZm9yIGFsbA0KICAgc3BlY2lmaWNhdGlvbiBuZWVkaW5nIHRoaXMgcmVw cmVzZW50YXRpb24uIA0KDQogICBDb21wYXRpYmlsaXR5IHdpdGggZXhpc3Rp bmcgU3RhbmRhcmQgVHJhY2sgc3BlY2lmaWNhdGlvbnMgKHN1Y2ggYXMNCiAg IFszXSBbNF0gWzVdIFs2XSkgaXMgYWxzbyBvbmUgb2YgdGhlIG1vc3QgaW1w b3J0YW50IGlzc3VlcyBpbiB0aGlzIA0KICAgc3BlY2lmaWNhdGlvbi4NCg0K DQoxLjEgVGVybWlub2xvZ3kgYW5kIFN5bnRheCBjb252ZW50aW9ucw0KDQog ICBJbiB0aGlzIGRvY3VtZW50IHRoZSBmb3JtYWwgZGVmaW5pdGlvbnMgYXJl IGRlc2NyaWJlZCB1c2luZyBBQk5GDQogICBzeW50YXgsIGFzIGRlZmluZWQg aW50byBbN10uIFRoaXMgbWVtbyBhbHNvIHVzZXMgc29tZSBvZiB0aGUgIkNP UkUNCiAgIERFRklOSVRJT05TIiBkZWZpbmVkIGluICJBUFBFTkRJWCBBIC0g Q09SRSIgb2YgdGhhdCBkb2N1bWVudC4gVGhlDQogICBleGFjdCBtZWFuaW5n IG9mIHRoZSBjYXBpdGFsaXNlZCB3b3Jkcw0KDQogICAgICAiTVVTVCIsICJN VVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCAi U0hPVUxEIiwNCiAgICAgICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwg ICJNQVkiLCAiT1BUSU9OQUwiDQoNCiAgIGlzIGRlZmluZWQgaW4gcmVmZXJl bmNlIFs4XS4NCg0KICAgSW4gdGhpcyBkb2N1bWVudCB0aGUgZm9sbG93aW5n IHRlcm1zIGFyZSBhbHNvIGRlZmluZWQ6DQoNCiAgICAgRGlhbCBTZXF1ZW5j ZToNCiAgICAgICAgYSBzZXJpZXMgb2YgRFRNRiBlbGVtZW50cyBhbmQgaHVt YW4gb3IgZGV2aWNlICJhY3Rpb25zIjsNCg0KICAgICBwaG9uZS1zdHJpbmc6 DQogICAgICAgIGEgdGV4dCByZXByZXNlbnRhdGlvbiBvZiBhIERpYWwgU2Vx dWVuY2U7DQoNCiAgICAgZ3N0bi1waG9uZToNCiAgICAgICAgYSB0ZXh0IHJl cHJlc2VudGF0aW9uIG9mIGEgR1NUTiBhZGRyZXNzICh3aGljaCBpbmNsdWRl cw0KICAgICAgICB0aGUgRS4xNjQgYWRkcmVzc2VzKTsNCg0KICAgICBzdWJh ZGRyLXN0cmluZzoNCiAgICAgICBhIHRleHQgcmVwcmVzZW50YXRpb24gb2Yg YSBHU1ROIHN1YmFkZHJlc3MgKHdoaWNoIGluY2x1ZGVzDQogICAgICAgSVNE TiBzdWJhZGRyZXNzZXMgWzJdIGFuZCBULjMzIHN1YmFkZHJlc3NlcyBbOV0p Ow0KDQogICAgIHBvc3QtZGlhbDoNCiAgICAgICBhIHRleHQgcmVwcmVzZW50 YXRpb24gb2YgYSBwb3N0IGRpYWxsaW5nIHNlcXVlbmNlLg0KDQoNCjIuIFRo ZSAiRGlhbCBTZXF1ZW5jZSIgZGVmaW5pdGlvbg0KDQogICBUaGUgcG9zc2li bGUgZWxlbWVudHMgY29tcG9zaW5nIGEgRGlhbCBTZXF1ZW5jZSBjYW4gdmFy eSBmcm9tIGEgDQogICBtaW5pbXVtIG51bWJlciB1cCB0byBhIHJlYWxseSBs YXJnZSBhbmQgY29tcGxleCBjb2xsZWN0aW9uOiBpbg0KICAgZmFjdCwgYWxy ZWFkeSB0aGUgc2VxdWVuY2VzIG5lZWRlZCB0byBkaWFsIGEgR1NUTiBhZGRy ZXNzLCB3aGljaCBpcw0KICAgYSBzdWJzZXQgb2YgdGhlIGdlbmVyaWMgRGlh bCBTZXF1ZW5jZSwgd2VsbCByZXByZXNlbnRzIHRoaXMgdmFyaWV0eQ0KICAg YW5kIGNvbXBsZXhpdHkgb2YgY2FzZXMuDQoNCiAgIEluIHBhcnRpY3VsYXIs IGEgRGlhbCBTZXF1ZW5jZSBpcyBjb21wb3NlZCBieToNCg0KICAgLSAiRFRN RiBlbGVsbWVudHMiOiBub3JtYWxseSBhdmFpbGFibGUgYXMgImtleXMiIG9u IG51bWVyaWMga2V5cGFkcw0KICAgICBvZiBkaWFsbGluZyBkZXZpY2VzOw0K DQogICAtICJhY3Rpb25zIjogbm9ybWFsbHkgcGVyZm9ybWVkIGJ5IHRoZSBh Z2VudCAoaHVtYW4gb3IgZGV2aWNlKSANCiAgICAgY29tcG9zaW5nIHRoZSBE aWFsIFNlcXVlbmNlOw0KDQogICAtICJzZXBhcmF0b3JzIjogdXNlZCBvbmx5 IHRvIGltcHJvdmUgaHVtYW4gcmVhZGliaWxpdHkgb2YgYSBEaWFsDQogICAg IFNlcXVlbmNlLg0KDQoNCjIuMSBUaGUgInBob25lLXN0cmluZyIgZGVmaW5p dGlvbg0KDQogICBUaGUgdGV4dCByZXByZXNlbnRhdGlvbiBvZiB0aGUgRGlh bCBTZXF1ZW5jZSBlbGVtZW50cyBpcyBkZWZpbmVkIA0KICAgaW50byB0aGUg cGhvbmUtc3RyaW5nIHNwZWNpZmljYXRpb246DQoNCiAgICAgIHBob25lLXN0 cmluZyA9IDEqKCBEVE1GIC8gcGF1c2UgLyB0b25ld2FpdCAvIHdyaXR0ZW4t c2VwICkNCg0KICAgICAgRFRNRiA9ICggRElHSVQgLyAiIyIgLyAiKiIgLyAi QSIgLyAiQiIgLyAiQyIgLyAiRCIgKQ0KICAgICAgICAgICAgICAgICAgICAg OyBzcGVjaWFsIERUTUYgY29kZXMgbGlrZSAiKiIsICIjIiwgIkEiLCAiQiIs DQogICAgICAgICAgICAgICAgICAgICA7ICJDIiwgIkQiIGFyZSBkZWZpbmVk IGluIFsxXS4NCiAgICAgICAgICAgICAgICAgICAgIDsgSW1wb3J0YW50IE5v dGU6IHRoZXNlIGVsZW1lbnRzIG9ubHkgYXBwbHkgZm9yDQogICAgICAgICAg ICAgICAgICAgICA7IGFscGhhYmV0aWMgc3RyaW5ncyB1c2VkIGluIERUTUYg b3BlcmF0aW9ucy4NCiAgICAgICAgICAgICAgICAgICAgIDsgVGhleSBhcmUg Tk9UIGFwcGxpY2FibGUgZm9yIHRoZSBhbHBoYWJldGljDQogICAgICAgICAg ICAgICAgICAgICA7IGNoYXJhY3RlcnMgdGhhdCBhcmUgbWFwcGVkIHRvIGRp Z2l0cyBvbiBwaG9uZQ0KICAgICAgICAgICAgICAgICAgICAgOyBrZXlwYWRz IGluIHNvbWUgY291bnRyaWVzLg0KDQogICAgICBwYXVzZSA9ICJwIg0KDQog ICAgICB0b25ld2FpdCA9ICJ3Ig0KDQogICAgICB3cml0dGVuLXNlcCA9ICgg Ii0iIC8gIi4iICkNCg0KICAgTm90ZToNCiAgICAgRFRNRiBhcmUgdGhlICJE VE1GIGVsZW1lbnRzIiwgcGF1c2UgYW5kIHRvbmV3YWl0IGFyZSB0aGUgImFj dGlvbnMiDQogICAgIGFuZCB3cml0dGVuLXNlcCBpcyB0aGUgInNlcGFyYXRv cnMiLg0KDQogICBUaGUgInBhdXNlIiBhbmQgInRvbmV3YWl0IiBlbGVtZW50 cyBpbnRlcnByZXRhdGlvbiBpbiBwaG9uZS1zdHJpbmcNCiAgIGRlcGVuZHMg b24gdGhlIHNwZWNpZmljIGRldmljZXMgYW5kIGltcGxlbWVudGF0aW9uIHVz aW5nIHRoZQ0KICAgc3BlY2lmaWNhdGlvbi4gVGh1cyB0aGVpciBleGFjdCBt ZWFuaW5nIGlzIG5vdCBkZWZpbmVkIGhlcmUgYXMgcGFydA0KICAgb2YgdGhp cyBzcGVjaWZpY2F0aW9uLiBUaGUgaW1wbGVtZW50ZXIncyBub3RlIGJlbG93 IGdpdmVzIGFueWhvdw0KICAgc29tZSByZWNvbW1lbmRhdGlvbnMgZHJvd24g ZnJvbSBjb21tb24gcHJhY3RpY2UuIEJvdGggInBhdXNlIiBhbmQNCiAgICJ0 b25ld2FpdCIgYXJlIGNhc2UgaW5zZW5zaXRpdmUuDQoNCiAgIEltcGxlbWVu dGVyJ3Mgbm90ZToNCiAgICAgLSBvbmUgaW5zdGFuY2Ugb2YgYSAicGF1c2Ui IGlzIHJlY29tbWVuZGVkIHRvIGJlIGludGVycHJldGVkIGFzDQogICAgICAg YSBwYXVzZSBvZiBvbmUgc2Vjb25kIGJldHdlZW4gdGhlIHByZWNlZGluZyBh bmQgc3VjY2VlZGluZyBkaWFsDQogICAgICAgc3RyaW5nIGVsZW1lbnQ7DQog ICAgIC0gYSAidG9uZXdhaXQiIGlzIHJlY29tbWVuZGVkIHRvIGJlIGludGVy cHJldGVkIGFzIGEgcGF1c2UgdGhhdCANCiAgICAgICB3aWxsIGxhc3QgdW50 aWwgdGhlIGNhbGxpbmcgcGFydHkgaGVhcnMgYSBkaWFsIHRvbmUgb3IgYW5v dGhlciANCiAgICAgICBpbmRpY2F0aW9uIHRoYXQgbW9yZSBkaWFsIHN0cmlu ZyBjaGFyYWN0ZXJzIG1heSBiZSBwcm9jZXNzZWQuIA0KICAgICAgIEFuIG9m Zi1ob29rIGluZGljYXRpb24gbWF5IGFsc28gYmUgaW50ZXJwcmV0ZWQgYXMg dGhpcyBraW5kIG9mIA0KICAgICAgIGluZGljYXRpb24gKG1lYW5pbmcgdGhh dCB0aGUgYXVkaW8gY2hhbm5lbCBoYXMgYmVlbiBvcGVuZWQgdG8gDQogICAg ICAgdGhlIHJlY2VpdmluZyBwYXJ0eSk7DQogICAgIC0gYmVjYXVzZSB0aGVz ZSBjaGFyYWN0ZXJzIGFyZSBub3QgYSBwYXJ0IG9mIHRoZSBHU1ROIHN1YnNj cmliZXIgDQogICAgICAgYWRkcmVzcyAodGVsZXBob25lIG51bWJlcikgcGVy IHNlLCBhbnkgZGlhbCBzdHJpbmcgY2hhcmFjdGVycyANCiAgICAgICB0aGF0 IHN1Y2NlZWQgZWl0aGVyIGEgInBhdXNlIiBvciAidG9uZXdhaXQiIHNob3Vs ZCBiZSBzZW50IHVzaW5nIA0KICAgICAgIERUTUYgc2lnbmFsbGluZy4NCg0K ICAgVGhlIHVzZSBvZiB3cml0dGVuLXNlcCBlbGVtZW50cyBpcyBhbGxvd2Vk IGluIG9yZGVyIHRvIGltcHJvdmUgDQogICBodW1hbiByZWFkaWJpbGl0eSBv ZiBwaG9uZS1zdHJpbmcuIFRoZSB3cml0dGVuLXNlcCBhcmUgZWxlbWVudHMN CiAgIHdoaWNoIGNhbiBiZSBwbGFjZWQgYmV0d2VlbiBkaWFsIGVsZW1lbnRz IHN1Y2ggYXMgZGlnaXRzIGV0Yy4NCiAgIEFueSBvY2N1cmVuY2VzIG9mIHdy aXR0ZW4tc2VwIGVsZW1lbnRzIGluIGEgcGhvbmUtc3RyaW5nIE1VU1QgTk9U DQogICByZXN1bHQgaW4gYW55IGFjdGlvbi4gQ29uZm9ybWFudCBpbXBsZW1l bnRhdGlvbnMgTUFZIGRyb3Agb3INCiAgIGluc2VydCB3cml0dGVuLXNlcCBp bnRvIHRoZSBwaG9uZS1zdHJpbmcgdGhleSBoYW5kbGUuDQoNCiAgIFRoZSBw aG9uZS1zdHJpbmcgZGVmaW5pdGlvbiBpcyB1c2VkIGluIHRoZSBmb2xsb3dp bmcgc2VjdGlvbnMgdG8NCiAgIGV4cGxpY2l0bHkgZGVzY3JpYmUgdGhlIGVu Y29kaW5nIG9mIHNvbWUgc3BlY2lmaWMgc3ViY2FzZXMgd2hlcmUNCiAgIGl0 IGFwcGxpZXMuDQoNCg0KMy4gVGhlICJnc3RuLXBob25lIiBkZWZpbml0aW9u DQoNCiAgIEluIG9yZGVyIHRvIGFjY2VzcyBhIEdTVE4gYWRkcmVzcywgYSBo dW1hbiBvciBhIGRldmljZSBtdXN0IHBlcmZvcm0NCiAgIGEgRGlhbCBTZXF1 ZW5jZS4gVGh1cyBhbHNvIGEgR1NUTiBhZGRyZXNzIGNhbiBiZSByZXByZXNl bnRlZCB1c2luZw0KICAgdGhlIHBob25lLXN0cmluZyBlbGVtZW50cy4gSW4g cGFydGljdWFsLCBzdGFuZGFyZCBFLjE2NCBudW1lcmljDQogICBhZGRyZXNz ZXMgWzJdIHJlcHJlc2VudCBhIGxpbWl0ZWQgc3Vic2V0IG9mIGFsbCBwb3Nz aWJsZSBHU1ROIA0KICAgYWRkcmVzc2VzLCB3aGlsZSB0aGUgY29tcGxldGUg Y29tcGxleCBjYXNlIG5lZWRzIGEgZnVsbCBlbmNvZGluZyANCiAgIHNjaGVt YS4gDQoNCiAgIEluIG9yZGVyIHRvIGRlc2NyaWJlIHRoaXMgZGlzdGluY3Rp b24gYW5kIHByb3ZpZGUgYW55aG93IGEgY29tcGxldGUNCiAgIGVuY29kaW5n IHNjaGVtYSwgdGhlIGZvbGxvd2luZyBkZWZpbml0aW9uIG9mICJnc3RuLXBo b25lIiBpcyBwcm92aWRlZDoNCg0KICAgICAgZ3N0bi1waG9uZSA9ICggZ2xv YmFsLXBob25lIC8gbG9jYWwtcGhvbmUgKQ0KDQoNCjMuMSBUaGUgImdsb2Jh bC1waG9uZSIgZGVmaW5pdGlvbg0KDQogICBUaGUgcHVycG9zZSBvZiBnbG9i YWwtcGhvbmUgZWxlbWVudCBpcyB0byByZXByZXNlbnQgc3RhbmRhcmQgRS4x NjQNCiAgIG51bWVyaWMgYWRkcmVzc2VzLiBBcyBzdWNoIGl0IHVzZXMgYSBz dWJzZXQgb2YgcGhvbmUtc3RyaW5nIA0KICAgZGVmaW5pdGlvbiwgb25seS4N Cg0KICAgVGhlIHN5bnRheCBmb3IgZ2xvYmFsLXBob25lIGVsZW1lbnQgaXMg YXMgZm9sbG93czoNCg0KICAgICAgZ2xvYmFsLXBob25lID0gIisiIDEqKCBE SUdJVCAvIHdyaXR0ZW4tc2VwICkNCg0KICAgQW55IG90aGVyIGRpYWxsaW5n IHNjaGVtZXMgTVVTVCBOT1QgdXNlIHRoZSBsZWFkaW5nICIrIiBkZWZpbmVk IGhlcmUuDQogICBUaGUgIisiIHNpZ24gaXMgc3RyaWN0bHkgcmVzZXJ2ZWQg Zm9yIHRoZSBzdGFuZGFyZCAiZ2xvYmFsLXBob25lIg0KICAgc3ludGF4LCBh bmQsIGV2ZW4gaWYgbm90IHNwZWNpZmljYWxseSBwYXJ0IG9mIHBob25lLXN0 cmluZyBkZWZpbml0aW9uLA0KICAgaXMgbmVlZGVkIHRvIGxhYmVsIHVuaXF1 ZWx5IGEgZ2xvYmFsLXBob25lLg0KDQoNCjMuMiBUaGUgImxvY2FsLXBob25l IiBkZWZpbml0aW9uDQoNCiAgIFRoZSBsb2NhbC1waG9uZSBlbGVtZW50IGlz IGludGVuZGVkIHRvIHJlcHJlc2VudCB0aGUgc2V0IG9mIHBvc3NpYmxlDQog ICBjYXNlcyB3aGVyZSB0aGUgZ2xvYmFsLXBob25lIG51bWJlcmluZyBzY2hl bWEgZG9lcyBub3QgYXBwbHkuIEdpdmVuDQogICB0aGUgZGlmZmVyZW50IGFu ZCBjb21wbGV4IGNvbnZlbnRpb25zIGN1cnJlbnRseSBiZWluZyB1c2VkIGlu IHRoZQ0KICAgR1NUTiBzeXN0ZW0sIHRoZSBsb2NhbC1waG9uZSBkZWZpbml0 aW9uIHN1cHBvcnRzIGEgbGFyZ2UgbnVtYmVyIG9mDQogICBlbGVtZW50cy4N Cg0KICAgVGhlIGRldGFpbGVkIHN5bnRheCBmb3IgbG9jYWwtcGhvbmUgZWxl bWVudHMgZm9sbG93czoNCg0KICAgICAgbG9jYWwtcGhvbmUgPSAgWyBleGl0 LWNvZGUgXSBkaWFsLW51bWJlcg0KDQogICAgICBsb2NhbC1waG9uZSA9LyBl eGl0LWNvZGUgWyBkaWFsLW51bWJlciBdDQoNCiAgICAgIGV4aXQtY29kZSA9 IHBob25lLXN0cmluZw0KICAgICAgICAgICAgICAgICAgOyB0aGlzIHdpbGwg aW5jbHVkZSBlbGVtZW50cyBzdWNoIGFzIHRoZSBkaWdpdCB0bw0KICAgICAg ICAgICAgICAgICAgOyBhY2Nlc3Mgb3V0c2lkZSBsaW5lLCB0aGUgbG9uZyBk aXN0YW5jZSBjYXJyaWVyDQogICAgICAgICAgICAgICAgICA7IGFjY2VzcyBj b2RlLCB0aGUgYWNjZXNzIHBhc3N3b3JkIHRvIHRoZSBzZXJ2aWNlLA0KICAg ICAgICAgICAgICAgICAgOyBldGMuLi4NCg0KICAgICAgZGlhbC1udW1iZXIg PSBwaG9uZS1zdHJpbmcNCiAgICAgICAgICAgICAgICAgIDsgdGhpcyBpcyBp biBtYW55IGNhc2VzIGNvbXBvc2VkIG9mIGRpZmZlcmVudCBlbGVtZW50cw0K ICAgICAgICAgICAgICAgICAgOyBzdWNoIGFzIHRoZSBsb2NhbCBwaG9uZSBu dW1iZXIsIHRoZSBhcmVhIGNvZGUNCiAgICAgICAgICAgICAgICAgIDsgKGlm IG5lZWRlZCksIHRoZSBpbnRlcm5hdGlvbmFsIGNvdW50cnkgY29kZQ0KICAg ICAgICAgICAgICAgICAgOyAoaWYgbmVlZGVkKSwgZXRjLi4uDQoNCiAgIE5v dGVzOg0KICAgICAgdGhlICIrIiBjaGFyYWN0ZXIgaXMgcmVzZXJ2ZWQgZm9y IHVzZSBpbiBnbG9iYWwtcGhvbmUgYW5kIE1VU1QgTk9UIA0KICAgICAgYmUg dXNlZCBpbiBhIGxvY2FsLXBob25lIHN0cmluZzsNCg0KICAgICAgcGxlYXNl IG5vdGUgdGhhdCBhIGxvY2FsLXBob25lIHN0cmluZyBNVVNUIE5PVCBiZSBh IG51bGwgc3RyaW5nLA0KICAgICAgaS5lLiBhdCBsZWFzdCBhbiBleGl0LWNv ZGUsIG9yIGEgZGlhbC1udW1iZXIgb3IgYm90aCBNVVNUIGJlDQogICAgICBw cmVzZW50Lg0KDQo0LiBUaGUgInN1YmFkZHItc3RyaW5nIiBkZWZpbml0aW9u DQoNCiAgIEluIEdTVE4gc2VydmljZSB0aGVyZSBhcmUgY2FzZXMgd2hlcmUg YSBzdWJhZGRyZXNzIGlzIHJlcXVpcmVkIHRvDQogICBzcGVjaWZ5IHRoZSBm aW5hbCBkZXN0aW5hdGlvbi4gVG8gc3BlY2lmeSB0aGVzZSBzdWJhZGRyZXNz ZXMgYSBEaWFsIA0KICAgU2VxdWVuY2UgaXMgYWxzbyB1c2VkLCBhbmQgdGh1 cyB0aGUgInN1YmFkZHItc3RyaW5nIiBjYW4gYmUgZW5jb2RlZA0KICAgYXM6 DQoNCiAgICAgIHN1YmFkZHItc3RyaW5nID0gcGhvbmUtc3RyaW5nDQoNCiAg IE5vdGU6IA0KICAgICAgd2l0aGluIGFjdHVhbCB1c2VzIG9mIHN1YmFkZHJl c3Nlcywgc29tZSBzcGVjaWZpYyBzZXJ2aWNlcyBjYW4NCiAgICAgIGxpbWl0 IHRoZSBwb3NzaWJsZSBzZXQgb2YgcGhvbmUtc3RyaW5nIGVsZW1lbnRzIGFs bG93ZWQuIEluIA0KICAgICAgcGFydGljdWxhciB0aGVyZSBhcmUgSVNETiBz dWJhZGRyZXNzZXMgWzJdIFs1XSwgd2hpY2ggcmVzdHJpY3QgdGhlIA0KICAg ICAgcGhvbmUtc3RyaW5nIGVsZW1lbnRzIHRvIDEqKCBESUdJVCAvIHdyaXR0 ZW4tc2VwICkgYW5kIHNlcnZpY2UgDQogICAgICBzcGVjaWZpYyBzdWJhZGRy ZXNzZXMsIGxpa2UgdGhlIGZheCBzZXJ2aWNlIFQuMzMgc3ViYWRkcmVzcyBb OV0NCiAgICAgIFs0XSB3aGljaCByZXN0cmljdCBwaG9uZS1zdHJpbmcgZWxl bWVudHMgdG8gMSooIERJR0lUICkuDQoNCg0KNS4gVGhlICJwb3N0LWRpYWwi IGRlZmluaXRpb24NCg0KICAgSW4gc29tZSBjYXNlcywgYWZ0ZXIgdGhlIGNv bm5lY3Rpb24gd2l0aCB0aGUgZGVzdGluYXRpb24gR1NUTiBkZXZpY2UNCiAg IGhhcyBiZWVuIGVzdGFibGlzaGVkLCBhIGZ1cnRoZXIgZGlhbGxpbmcgc2Vx dWVuY2UgaXMgcmVxdWlyZWQgdG8NCiAgIGFjY2VzcyBmdXJ0aGVyIHNlcnZp Y2VzLiBBIHR5cGljYWwgZXhhbXBsZSBpcyBhbiBhdXRvbWF0ZWQgbWVudS0N CiAgIGRyaXZlbiBzZXJ2aWNlIHVzaW5nIERUTUYgc2VxdWVuY2VzLiBUaGVz ZSBjYXNlcyBtYXkgYmUgcmVwcmVzZW50ZWQNCiAgIHVzaW5nICJwb3N0LWRp YWwiIGRlZmluaXRpb24gYmVsb3c6DQoNCiAgICAgIHBvc3QtZGlhbCA9IHBo b25lLXN0cmluZw0KDQoNCjYuIEV4YW1wbGVzDQoNCiAgIEluIG9yZGVyIHRv IGNsYXJpZnkgdGhlIHNwZWNpZmljYXRpb24gd2UgcHJlc2VudCBoZXJlIGEg bGltaXRlZCBzZXQNCiAgIG9mIGV4YW1wbGVzLiBQbGVhc2Ugbm90ZSB0aGF0 IGFsbCB0aGUgZXhhbXBsZXMgYXJlIGZvciBpbGx1c3RyYXRpb24gDQogICBw dXJwb3VzZXMsIG9ubHkuDQoNCiAgIEEgR1NUTiBhZGRyZXNzIGluIEl0YWx5 LCBkaWFsbGVkIGZyb20gVS5TLkEuLCB1c2luZyBsb2NhbC1waG9uZSwgDQog ICB3aXRob3V0IHdyaXR0ZW4tc2VwOg0KDQogICAgICAwMTEzOTA0MDIyNjMz OA0KDQogICBBIEdTVE4gYWRkcmVzcyBhZGRyZXNzIGluIEdlcm1hbnksIHVz aW5nIGdsb2JhbC1waG9uZSBhbmQgDQogICB3cml0dGVuLXNlcCAiLiI6DQoN CiAgICAgICs0OS44MS43ODU2MzQ1DQoNCiAgIEEgR1NUTiBhZGRyZXNzIGlu IFUuUy5BLiB1c2luZyBnbG9iYWwtcGhvbmUgYW5kIHdyaXR0ZW4tc2VwICIt IjoNCg0KICAgICAgKzEtMjAyLTQ1NS03NjIyDQoNCiAgIEEgcG9zdC1kaWFs IHNlcXVlbmNlLCBwYXVzaW5nLCBkaWFsbGluZyAxLCB3YWl0aW5nIGZvciBk aWFsIHRvbmUsIA0KICAgZGlhbGxpbmcgNzAwNTM5Mywgd2FpdGluZyBhZ2Fp biBmb3IgZGlhbCB0b25lIGFuZCBkaWFsbGluZyAzNzM7IA0KICAgbm90ZSB0 aGUgdXNlIG9mIGZvdXIgInAiIGVsZW1lbnRzIChwcHBwKSB0byBzcGVjaWZ5 IGEgbG9uZ2VyIGluaXRpYWwNCiAgIHBhdXNlOg0KDQogICAgICBwcHBwMXc3 MDA1MzkzdzM3Mw0KDQogICBBIERpYWwgU2VxdWVuY2UgaW4gSXRhbHkgKGxv bmcgZGlzdGFuY2UgY2FsbCksIHVzaW5nIGxvY2FsLXBob25lLCANCiAgIHdp dGggZXhpdC1jb2RlICI5IiwgbG9uZyBkaXN0YW50IGFjY2VzcyAiMCIsIGFy ZWEgY29kZSAiNDAiLA0KICAgcGF1c2UgInAiIGFuZCB3cml0dGVuLXNlcCAi LiI6DQoNCiAgICAgIDlwMDQwcDIyLjYzLjM4DQoNCiAgIEEgRGlhbCBTZXF1 ZW5jZSB1c2luZyBleGl0LWNvZGUgIjAiLCBhIHdhaXQgZm9yIGRpYWwgdG9u ZSwgDQogICBsb2NhbC1waG9uZSBmb3IgYW4gSW50ZXJuYXRpb25hbCAiODAw IiB0b2xsLWZyZWUgbnVtYmVyIGRpYWxsZWQNCiAgIGZyb20gQmVnbGl1bSAo aW50ZXJuYXRpb25hbCBwcmVmaXggIjAwIiksIGFuZCBhIHBvc3QtZGlhbCBz ZXF1ZW5jZSANCiAgIHRvIGFjY2VzcyBhIHZvaWNlIG1haWxib3ggd2l0aCB1 c2VySUQgIjMzNDQyMiIgYW5kIFBlcnNvbmFsIA0KICAgSWRlbnRpZmljYXRp b24gTnVtYmVyIChQSU4pIGNvZGUgIjEyMzQiOg0KDQogICAgICAwdzAwODAw LTM5MzgwMDIzcHAzMzQ0MjJwMTIzNA0KDQo3LiBDb25jbHVzaW9ucw0KDQog ICBUaGlzIHByb3Bvc2FsIGNyZWF0ZXMgYSBmdWxsIHN0YW5kYXJkIHRleHQg ZW5jb2RpbmcgZm9yIERpYWwNCiAgIFNlcXVlbmNlcywgaW5jbHVkaW5nIEdT VE4gLyBFLjE2NCBhZGRyZXNzZXMsIGFuZCB0aHVzIHByb3ZpZGVzIGENCiAg IHVuaXF1ZSBjb21tb24gcmVwcmVzZW50YXRpb24gbWV0aG9kIGJvdGggZm9y IHN0YW5kYXJkIHByb3RvY29scw0KICAgYW5kIGFwcGxpY2F0aW9ucy4gDQoN CiAgIFNvbWUgZGVmaW5pdGlvbnMsIGxpa2UgdGhlc2UgY29ycmVzcG9uZGlu ZyB0byBhbiBhbGlhcyBvZiB0aGUgZ2VuZXJpYyANCiAgIHBob25lLXN0cmlu ZyBlbGVtZW50LCBhcmUgc29tZXdoYXQgYSB0aGVvcmV0aWNhbCBkaXN0aW5j dGlvbjsgaG93ZXZlcg0KICAgdGhleSBhcmUgdXNlZnVsIHRvIHByb3ZpZGUg YSBtb3JlIHN1YnRsZSBkaXN0aW5jdGlvbiwgYWxsb3dpbmcgb3RoZXINCiAg IHNwZWNpZmljYXRpb25zIHRvIGJlIG1vcmUgZXhhY3QgaW4gYSBjb25zaXN0 ZW50IHdheSwgdG9vLg0KDQogICBUaGUgcHJvcG9zYWwgaXMgY29uc2lzdGVu dCB3aXRoIGV4aXN0aW5nIHN0YW5kYXJkIHNwZWNpZmljYXRpb25zLg0KDQoN CjguIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1l bnQgc3BlY2lmaWVzIGEgbWVhbnMgdG8gcmVwcmVzZW50IERpYWwgU2VxdWVu Y2VzLCB3aGljaA0KICAgdGh1cyBjb3VsZCBpbmNsdWRlIEdTVE4gYWRkcmVz c2VzLCBhbmQgcHJpdmF0ZSBjb2RlcyBzZXF1ZW5jZXMsDQogICBsaWtlIFBl cnNvbmFsIElkZW50aWZpY2F0aW9uIE51bWJlcnMsIHRvIGFjY2VzcyBzcGVj aWFsIHNlcnZpY2VzLg0KICAgQXMgdGhlc2UgdGV4dCBzdHJpbmdzIGNvdWxk IGJlIHRyYW5zbWl0dGVkIHdpdGhvdXQgZW5jb2RpbmcgaW5zaWRlDQogICBw cm90b2NvbHMgb3IgYXBwbGljYXRpb25zIHNlcnZpY2VzLCB0aGlzIGNvdWxk IGFsbG93IHVuYXV0aG9yaXplZA0KICAgcGVvcGxlIHRvIGdhaW4gYWNjZXNz IHRvIHRoZXNlIGNvZGVzLiBVc2VycyBTSE9VTEQgYmUgcHJvdmlkZWQgbWV0 aG9kcw0KICAgdG8gcHJldmVudCB0aGlzIGRpc2Nsb3N1cmUsIGxpa2UgY29k ZSBlbmNyeXB0aW9uLCBvciBtYXNxdWVyYWRpbmcNCiAgIHRlY2huaXF1ZXM6 IG91dC1vZi1iYW5kIGNvbW11bmljYXRpb24gb2YgYXV0aG9yaXphdGlvbiBp bmZvcm1hdGlvbiBvcg0KICAgdXNlIG9mIGVuY3J5cHRlZCBkYXRhIGluIHNw ZWNpYWwgZmllbGRzIGFyZSB0aGUgYXZhaWxhYmxlIG5vbi1zdGFuZGFyZA0K ICAgdGVjaG5pcXVlcy4NCg0KDQo5LiBDb2xsZWN0ZWQgQUJORiBTeW50YXgN Cg0KICAgSW4gdGhpcyBzZWN0aW9uIHdlIHByb3ZpZGUgYSBzdW1tYXJ5IG9m IEFCTkYgc3BlY2lmaWNhdGlvbnMuDQoNCiAgICAgIHBob25lLXN0cmluZyA9 IDEqKCBEVE1GIC8gcGF1c2UgLyB0b25ld2FpdCAvIHdyaXR0ZW4tc2VwICkN Cg0KICAgICAgRFRNRiA9ICggRElHSVQgLyAiIyIgLyAiKiIgLyAiQSIgLyAi QiIgLyAiQyIgLyAiRCIgKQ0KDQogICAgICB3cml0dGVuLXNlcCA9ICggIi0i IC8gIi4iICkNCg0KICAgICAgcGF1c2UgPSAicCINCg0KICAgICAgdG9uZXdh aXQgPSAidyINCg0KICAgICAgZ3N0bi1waG9uZSA9ICggZ2xvYmFsLXBob25l IC8gbG9jYWwtcGhvbmUgKQ0KDQogICAgICBnbG9iYWwtcGhvbmUgPSAiKyIg MSooIERJR0lUIC8gd3JpdHRlbi1zZXAgKQ0KDQogICAgICBsb2NhbC1waG9u ZSA9ICBbIGV4aXQtY29kZSBdIGRpYWwtbnVtYmVyDQoNCiAgICAgIGxvY2Fs LXBob25lID0vIGV4aXQtY29kZSBbIGRpYWwtbnVtYmVyIF0NCg0KICAgICAg ZXhpdC1jb2RlID0gcGhvbmUtc3RyaW5nDQoNCiAgICAgIGRpYWwtbnVtYmVy ID0gcGhvbmUtc3RyaW5nDQoNCiAgICAgIHN1YmFkZHItc3RyaW5nID0gcGhv bmUtc3RyaW5nDQoNCiAgICAgIHBvc3QtZGlhbCA9IHBob25lLXN0cmluZw0K DQoNCjEwLiBBdXRob3IncyBBZGRyZXNzDQoNCiAgIENsYXVkaW8gQWxsb2Nj aGlvDQogICBJTkZOLUdBUlINCiAgIGMvbyBTaW5jcm90cm9uZSBUcmllc3Rl DQogICBTUyAxNCBLbSAxNjMuNSBCYXNvdml6emENCiAgIEkgMzQwMTIgVHJp ZXN0ZQ0KICAgSXRhbHkNCg0KICAgUkZDMjgyMjogQ2xhdWRpby5BbGxvY2No aW9AZ2Fyci5pdA0KICAgWC40MDA6ICAgQz1pdDtBPWdhcnI7UD1nYXJyO1M9 QWxsb2NjaGlvO0c9Q2xhdWRpbzsNCiAgIFBob25lOiAgICszOSAwNDAgMzc1 ODUyMw0KICAgRmF4OiAgICAgKzM5IDA0MCAzNzU4NTY1DQoNCg0KMTEuIFJl ZmVyZW5jZXMNCg0KICAgWzFdICBFVFNJIEktRVRTIDMwMCwzODAgLSBVbml2 ZXJzYWwgUGVyc29uYWwgVGVsZWNvbW11bmljYXRpb24NCiAgICAgICAgKFVQ VCk6IEFjY2VzcyBEZXZpY2VzIER1YWwgVG9uZSBNdWx0aSBGcmVxdWVuY3kg KERUTUYpIHNlbmRlcg0KICAgICAgICBmb3IgYWNvdXN0aWNhbCBjb3VwbGlu ZyB0byB0aGUgbWljcm9waG9uZSBvZiBhIGhhbmRzZXQgdGVsZXBob25lDQog ICAgICAgIChNYXJjaCAxOTk1KQ0KDQogICBbMl0gIElUVSBFLjE2NCAtIFRo ZSBJbnRlcm5hdGlvbmFsIFB1YmxpYyBUZWxlY29tbXVuaWNhdGlvbiBOdW1i ZXJpbmcNCiAgICAgICAgUGxhbiBFLjE2NC9JLjMzMSAoTWF5IDE5OTcpDQoN CiAgIFszXSAgQWxsb2NjaGlvLCBDLiwgIk1pbmltYWwgR1NUTiBhZGRyZXNz IGZvcm1hdCBpbiBJbnRlcm5ldCBNYWlsIiwNCiAgICAgICAgUkZDIDMxOTEs IE9jdG9iZXIgMjAwMQ0KDQogICBbNF0gIEFsbG9jY2hpbywgQy4sICJNaW5p bWFsIEZBWCBhZGRyZXNzIGZvcm1hdCBpbiBJbnRlcm5ldCBNYWlsIiwNCiAg ICAgICAgUkZDIDMxOTIsIE9jdG9iZXIgMjAwMQ0KDQogICBbNV0gIEFsbG9j Y2hpbywgQy4gIkdTVE4gYWRkcmVzcyBlbGVtZW50IGV4dGVuc2lvbnMgaW4g ZS1tYWlsIA0KICAgICAgICBzZXJ2aWNlcyIsIFJGQyAyODQ2LCBKdW5lIDIw MDAuDQoNCiAgIFs2XSAgVmFoYS1TaXBpbGEsIEEuLCAiVVJMcyBmb3IgVGVs ZXBob25lIENhbGxzIiwgUkZDIDI4MDYsIA0KICAgICAgICBBcHJpbCAyMDAw Lg0KDQogICBbN10gIENyb2NrZXIsIEQuIGFuZCBQLiBPdmVyZWxsLCAiQXVn bWVudGVkIEJORiBmb3IgU3ludGF4DQogICAgICAgIFNwZWNpZmljYXRpb25z IiwgUkZDIDIyMzQsIE5vdmVtYmVyIDE5OTcuDQoNCiAgIFs4XSAgQnJhZG5l ciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRl IFJlcXVpcmVtZW50DQogICAgICAgIExldmVscyIsIEJDUCAxNCwgUkZDIDIx MTksIE1hcmNoIDE5OTcuDQoNCiAgIFs5XSAgSVRVIFQuMzMgLSBGYWNzaW1p bGUgcm91dGluZyB1dGlsaXppbmcgdGhlIHN1YmFkZHJlc3M7DQogICAgICAg IHJlY29tbWVuZGF0aW9uIFQuMzMgKEp1bHksIDE5OTYpDQoNCg0KDQoxMi4g IEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMp IFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4gIEFsbCBSaWdodHMgUmVz ZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBv ZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8NCiAgIG90aGVy cywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90 aGVyd2lzZSBleHBsYWluIGl0DQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxl bWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQN CiAgIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0 aG91dCByZXN0cmljdGlvbiBvZiBhbnkNCiAgIGtpbmQsIHByb3ZpZGVkIHRo YXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdy YXBoIGFyZQ0KICAgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBk ZXJpdmF0aXZlIHdvcmtzLiAgSG93ZXZlciwgdGhpcw0KICAgZG9jdW1lbnQg aXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdheSwgc3VjaCBh cyBieSByZW1vdmluZw0KICAgdGhlIGNvcHlyaWdodCBub3RpY2Ugb3IgcmVm ZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBvdGhlcg0KICAg SW50ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBmb3Ig dGhlIHB1cnBvc2Ugb2YNCiAgIGRldmVsb3BpbmcgSW50ZXJuZXQgc3RhbmRh cmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9yDQogICBjb3B5 cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVybmV0IFN0YW5kYXJkcyBwcm9j ZXNzIG11c3QgYmUNCiAgIGZvbGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byB0 cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbg0KICAgRW5n bGlzaC4NCg0KICAgVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBh Ym92ZSBhcmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBiZQ0KICAgcmV2b2tl ZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBv ciBhc3NpZ25zLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm92aWRlZCBvbiBhbg0KICAg IkFTIElTIiBiYXNpcyBhbmQgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRI RSBJTlRFUk5FVCBFTkdJTkVFUklORw0KICAgVEFTSyBGT1JDRSBESVNDTEFJ TVMgQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwgSU5DTFVE SU5HDQogICBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQg VEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04NCiAgIEhFUkVJTiBXSUxMIE5P VCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJ RVMgT0YNCiAgIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBB UlRJQ1VMQVIgUFVSUE9TRS4NCg== --5692-1103527590-1014374169=:559949238-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 04:51:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25466 for ; Fri, 22 Feb 2002 04:51:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09540 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 04:51:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08633; Fri, 22 Feb 2002 04:41:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08602 for ; Fri, 22 Feb 2002 04:41:36 -0500 (EST) Received: from 192.168.181.1 (suntec01.i-dns.net [203.126.116.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25208 for ; Fri, 22 Feb 2002 04:41:31 -0500 (EST) Message-ID: <002b01c1bb85$0b4e9b70$c100a8c0@maynardibm> From: "Maynard Kang" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , References: <7698459.1014326952@localhost> <002101c1bb44$afff5100$0c64a8c0@maynardibm> <9894809.1014363557@localhost> Subject: Re: [Enum] 2916bis Date: Fri, 22 Feb 2002 17:41:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-GCMulti: 1 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > Interesting. I have personally been working a lot with RFC 2483 and others, > but this is the first time I hear someone binding the NAPTR service field > to that RFC. > What was the original intention of that document anyway? I notice it is an experimental RFC. > Originally E2U was picked just because the string "E.164" start with 'E' > and "URI" start with 'U'. :-) Yup, guess that as much :-) regards, maynard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 04:52:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25501 for ; Fri, 22 Feb 2002 04:52:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09575 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 04:52:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08695; Fri, 22 Feb 2002 04:42:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08667 for ; Fri, 22 Feb 2002 04:42:13 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25218 for ; Fri, 22 Feb 2002 04:42:08 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062731; Fri, 22 Feb 2002 09:42:07 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <10230684.1014369154@localhost> References: <20020221085152.L26811@bailey.dscga.com> <10230684.1014369154@localhost> Date: Fri, 22 Feb 2002 09:42:00 +0000 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Michael Mealling From: Lawrence Conroy Cc: enum@ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA08668 Subject: [Enum] Re: NAPTR Service field contents & CNAMEs Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 9:12 am +0100 22/2/02, Patrik F�ltstr�m wrote: >--On 2002-02-21 16.30 +0000 Lawrence Conroy wrote: > >> Whilst you're at this, why not re-consider the names of these sub-fields. > >We now only talk about "enumservice". > To which I reply (as in my 2916bis comments): Absolutely fine - I'm much happier with enumservice than protocol & rs. Re. rumour of tel doc. Rudi & I have been trying to put something down in black & white electrons. Today we'll re-touch it to fit with the template and ABNF in 2916bis. Please don't change it back. Re. CNAME considered harmful, or at least might give a hangover, or perhaps is not good for the heart, or ... DNSOP is the place to be? Thanks - Just what I need is registering for another mailing list :( SIP/SIPPING/SIP-IMP/... isn't enough traffic already ). The issue here is that, if one CAN use CNAME, then it looks like you don't need to re-submit a new ENUM query with the content of a tel: URI. Unless there's some big reason why this WILL not work, then I will put into the tel: spec that re-submission is disrecommended, with a warning that looping may be someone else's mistake, but it's your problem, as you re-submitted. br, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 04:57:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25637 for ; Fri, 22 Feb 2002 04:57:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09871 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 04:57:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09331; Fri, 22 Feb 2002 04:49:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09228 for ; Fri, 22 Feb 2002 04:49:02 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25368 for ; Fri, 22 Feb 2002 04:48:59 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA05582; Fri, 22 Feb 2002 10:48:25 +0100 (MET) Date: Fri, 22 Feb 2002 10:48:09 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , Michael Mealling cc: enum@ietf.org Message-ID: <10574758.1014374889@localhost> In-Reply-To: References: <20020221085152.L26811@bailey.dscga.com> <10230684.1014369154@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Enum] Re: NAPTR Service field contents & CNAMEs Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-22 09.42 +0000 Lawrence Conroy wrote: > The issue here is that, if one CAN use CNAME, then it looks like you > don't need to re-submit a new ENUM query with the content of a tel: > URI. Unless there's some big reason why this WILL not work, then I > will put into the tel: spec that re-submission is disrecommended, > with a warning that looping may be someone else's mistake, but it's > your problem, as you re-submitted. Some DNS information: If you have a CNAME for an owner, you can not have _anything_else_ in the same RR-set. I.e. if you have a CNAME which is foo.paf.se, you can not also have a NAPTR for foo.paf.se. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 05:10:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25935 for ; Fri, 22 Feb 2002 05:10:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10884 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 05:10:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10525; Fri, 22 Feb 2002 05:02:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10496 for ; Fri, 22 Feb 2002 05:02:06 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25740; Fri, 22 Feb 2002 05:01:59 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062732; Fri, 22 Feb 2002 10:01:59 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: References: Date: Fri, 22 Feb 2002 10:01:56 +0000 To: Claudio Allocchio , internet-drafts@ietf.org From: Lawrence Conroy Subject: Re: [Enum] DRAFT-ALLOCCHIO-GSTN-02.TXT Updated version Cc: ietf-fax@imc.org, discuss@apps.ietf.org, enum@ietf.org, ietf@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 10:36 am +0100 22/2/02, Claudio Allocchio wrote: >Hallo, > >here is the updated version of DRAFT-ALLOCCHIO-GSTN-02.TXT, which >includes, as the only difference from the previous one, an "implementer's >note" regarding 'pause' and 'tonewait' which was suggested as helpful. > >As mentioned in the first release of the draft, "the intention for this >document is to provide a unique syntax for Dial Sequences, including >expecially phone numbers as a subset. The definitions contained in the >draft actually come from existing Draft Standard and Proposed Standard >specifications, but were collected here to provide a quick, easy and >unique reference document for anybody needing this particualr encoding. >The original idea comes from the Application Area Directors, and I made >the collection and edited the I-D." > >I kindly invite you to provide me your comments and suggestions! > >Thank you all, and regards! > >Claudio Allocchio >ietf fax wg co-chair I am pretty bemused at this - I seem to have missed the earlier ones. The Application ADs suggested it? What exactly does this add to RFC2806? It doesn't seem to update 2806, so I don't understand how I use this, or where. In particular, the phone-context stuff in 2806 is there for a good reason - the phone string could well be sent to Finland (inside an email, for instance). This is not going to work if one uses local phone string format (with 001 to call the U.S.). It doesn't seem to be in this draft, so perhaps a warning that this will break unless you KNOW where the recipient will be dialling could be (re-)added? Hey, I'm sure you don't have anything else to do before 2300 MET, right? :). BR, L -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 05:28:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26184 for ; Fri, 22 Feb 2002 05:28:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA11628 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 05:28:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11310; Fri, 22 Feb 2002 05:19:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11279 for ; Fri, 22 Feb 2002 05:19:50 -0500 (EST) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26043; Fri, 22 Feb 2002 05:19:46 -0500 (EST) Date: Fri, 22 Feb 2002 11:19:30 +0100 To: Lawrence Conroy cc: ietf-fax@imc.org, discuss@apps.ietf.org, enum@ietf.org, ietf@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: [Enum] DRAFT-ALLOCCHIO-GSTN-02.TXT Updated version Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hallo, > I am pretty bemused at this - I seem to have missed the earlier ones. > The Application ADs suggested it? yes sir! > What exactly does this add to RFC2806? > It doesn't seem to update 2806, so I don't understand how I use this, > or where. I think you missed the main point here. RFC2806, RFC3191, RFC3192, and a large number of rfc-to-be from the VPIM WG in the RFC Editor queue now all use the syntax and specification contained into DRAFT-ALLOCCHIO-GSTN-02.TXT and thus are all compatible with it. Thus this document does not add or updated any of them at all (all authors of the above documents are those who contributed to this I-D). However the specifications are embedded into RFCs whose title and purpouse is not to sepcify how you write in text a dial string sequence, and this creates continuously the "re-invent the wheel" problem, and the ADs and IESG has to send back specifications asking the authors to use the existing standard specification. If there is a single "collection" document with a sensible title, and which is free from other definitions which might confuse the reader, the "keeping the coherence" job is easier. > In particular, the phone-context stuff in 2806 is there for a good reason > - the phone string could well be sent to Finland (inside an email, for > instance). This is not going to work if one uses local phone string > format (with 001 to call the U.S.). Local Phone string can work only "locally", and global-phone ones do their job globally. If you think the text is not clear enough, we can try to clarify it. > Hey, I'm sure you don't have anything else to do before 2300 MET, right? :). ... I'm just waiting the kernel to rebuild after I included IPv6 on my workstation... thus I have some time... :-) Regards Claudio _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 05:44:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26397 for ; Fri, 22 Feb 2002 05:44:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12691 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 05:44:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12303; Fri, 22 Feb 2002 05:35:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12275 for ; Fri, 22 Feb 2002 05:35:37 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26268 for ; Fri, 22 Feb 2002 05:35:32 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.224]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g1MAY9tQ024594; Fri, 22 Feb 2002 11:34:09 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Feb 2002 11:09:49 +0100 Message-ID: From: "Stastny, Richard" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , Lawrence Conroy , Michael Mealling Cc: enum@ietf.org Subject: RE: [Enum] Re: NAPTR Service field contents & CNAMEs Date: Fri, 22 Feb 2002 11:09:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >Patrik wrote: > > --On 2002-02-22 09.42 +0000 Lawrence Conroy wrote: > > > The issue here is that, if one CAN use CNAME, then it > looks like you > > don't need to re-submit a new ENUM query with the > content of a tel: > > URI. Unless there's some big reason why this WILL not > work, then I > > will put into the tel: spec that re-submission is disrecommended, > > with a warning that looping may be someone else's > mistake, but it's > > your problem, as you re-submitted. > > Some DNS information: If you have a CNAME for an owner, you > can not have > _anything_else_ in the same RR-set. > > I.e. if you have a CNAME which is foo.paf.se, you can not > also have a NAPTR > for foo.paf.se. > That fits exactly the intended use: if you have 3 phone numbers in ENUM and want to put ALL NAPTR records in one basket, you put CNAME in the other 2 and nothing else. Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 22 06:58:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28396 for ; Fri, 22 Feb 2002 06:58:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA16422 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 06:58:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16142; Fri, 22 Feb 2002 06:48:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16111 for ; Fri, 22 Feb 2002 06:48:53 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28150 for ; Fri, 22 Feb 2002 06:48:51 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1MBi8186633; Fri, 22 Feb 2002 03:44:08 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202221144.g1MBi8186633@nic-naa.net> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: Eric Brunner-Williams in Portland Maine , "Stastny, Richard" , "'Christian Huitema'" , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemm a) In-Reply-To: Your message of "Fri, 22 Feb 2002 09:25:35 +0100." <10277519.1014369935@localhost> Date: Fri, 22 Feb 2002 06:44:08 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > The issues China has with e164.arpa has nothing to do with ENUM, but other > more political things. Yup. I saw their text. > I spent quite some time with them in Geneva, and the text passed _can_ (and > I think is) blown to proportions which is not of the same scale as the > actual discussions. I had that impression after reading the original, bandwidth, latency, scale, all reasonable concerns, and not identical with foo-is-call-setup as someone suggested. > China supported the use of e164.arpa and the instructions to TSB, but, > wanted an examination of locations of the root and arpa nameservers (which > is an RSAC issue). I.e. they wanted more data and experiments on impact on > doing ENUM during call setup, and I think that is fair. Yup on the RSAC issue. Data and experiments are always good, or at least better than the alternative. > "China" included people which sent in the request to RIPE NCC for > delegation of their E.164 CC, so there is support. Much more than what > readers of this list might think. I started working towards feasibility and proof-of-concept in September, with actual trials in November. The E.164 CC delegation wasn't available so we improvised _without_ signifigance where delegations were available. > Can we go back to discuss 2916bis and relevant documents please? Yup. EOT. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 22 07:28:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29426 for ; Fri, 22 Feb 2002 07:28:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18545 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 07:28:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17933; Fri, 22 Feb 2002 07:19:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17907 for ; Fri, 22 Feb 2002 07:19:34 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29119 for ; Fri, 22 Feb 2002 07:19:31 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA06413; Fri, 22 Feb 2002 13:19:28 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA21577; Fri, 22 Feb 2002 13:19:24 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 13:19:31 +0100 Message-ID: From: Brandner Rudolf To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: enum@ietf.org Subject: AW: [Enum] 2916bis - more initial review Date: Fri, 22 Feb 2002 13:19:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Patrik, some additional nits on 2916bis: line 402: suppose it was meant "...devastating results." line 433: should read "registration" instead of "egistration" line 438-440: Could not parse that sentence, maybe it is misformed or maybe due to the fact that my native language is not English Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 22 09:31:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03479 for ; Fri, 22 Feb 2002 09:31:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25301 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 09:31:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24438; Fri, 22 Feb 2002 09:22:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24409 for ; Fri, 22 Feb 2002 09:22:32 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03105 for ; Fri, 22 Feb 2002 09:22:28 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1MEI7I2010470; Fri, 22 Feb 2002 09:18:07 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1MEI6mg010469; Fri, 22 Feb 2002 09:18:06 -0500 (EST) Date: Fri, 22 Feb 2002 09:18:06 -0500 From: Michael Mealling To: Maynard Kang Cc: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , enum@ietf.org Subject: Re: [Enum] 2916bis Message-ID: <20020222091806.J8392@bailey.dscga.com> Reply-To: Michael Mealling References: <7698459.1014326952@localhost> <002101c1bb44$afff5100$0c64a8c0@maynardibm> <9894809.1014363557@localhost> <002b01c1bb85$0b4e9b70$c100a8c0@maynardibm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002b01c1bb85$0b4e9b70$c100a8c0@maynardibm> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Fri, Feb 22, 2002 at 05:41:01PM +0800, Maynard Kang wrote: > > Interesting. I have personally been working a lot with RFC 2483 and > > others, > > but this is the first time I hear someone binding the NAPTR service field > > to that RFC. > > > > What was the original intention of that document anyway? I notice it is an > experimental RFC. URI Resolution uses it as a way to grossly classify URI related services. I personally think it has at least some applicability in the web world with things like web services since those are operations on URIs and their Resources. > > Originally E2U was picked just because the string "E.164" start with 'E' > > and "URI" start with 'U'. :-) > > Yup, guess that as much :-) I have to agree. I really don't think 2483 is really applicable here. Especially since the input isn't a URI. One of the main points of 2483 was that a URI is self typing so you didn't need to specify the input, just the operation and the output. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 22 09:44:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03902 for ; Fri, 22 Feb 2002 09:44:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26006 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 09:44:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25629; Fri, 22 Feb 2002 09:36:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25588 for ; Fri, 22 Feb 2002 09:36:09 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03657 for ; Fri, 22 Feb 2002 09:36:03 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16eGnH-000Ctw-00; Fri, 22 Feb 2002 06:35:27 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: enum@ietf.org Subject: Re: [Enum] RE: ENUM Part of Call Setup (Was: Implementer's dilemma) References: <200202211550.g1LFo1182952@nic-naa.net> <10277519.1014369935@localhost> Message-Id: Date: Fri, 22 Feb 2002 06:35:27 -0800 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > China supported the use of e164.arpa and the instructions to TSB, but, > wanted an examination of locations of the root and arpa nameservers (which > is an RSAC issue). the location of arpa servers is _not_ an rsac, or any part of icann, issue. > "China" included people which sent in the request to RIPE NCC for > delegation of their E.164 CC, so there is support. exactly. many countries are voting with their feet while politicians electioneer with their keyboards. it's amusing when one sees the larger picture. randy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 22 09:56:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04415 for ; Fri, 22 Feb 2002 09:55:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26772 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 09:56:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26187; Fri, 22 Feb 2002 09:47:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26125 for ; Fri, 22 Feb 2002 09:47:20 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03955 for ; Fri, 22 Feb 2002 09:47:14 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id GAA21399; Fri, 22 Feb 2002 06:46:31 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 06:46:31 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B014B1016@opwinex01.corp.illuminet.com> From: Kevin McCandless To: "'enum@ietf.org'" Cc: "'bdutcher@versigin.com'" Date: Fri, 22 Feb 2002 06:46:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBAF.B62259E0" Subject: [Enum] ENUM individual draft on root domain. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@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. ------_=_NextPart_001_01C1BBAF.B62259E0 Content-Type: text/plain; charset="iso-8859-1" Here is the link to the updated draft from Bill and myself on ENUM root domain. We wanted to share our opinions and thoughts with you on this issue. You can find the updated draft at the URL below. http://www.ietf.org/internet-drafts/draft-dutcher-enum-root-domain-01.txt Sincerely, Kevin........ ------_=_NextPart_001_01C1BBAF.B62259E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Here = is the link to=20 the updated draft from Bill and myself on ENUM root domain.  We = wanted to=20 share our opinions and thoughts with you on this = issue.
 
You = can find the=20 updated draft at the URL below.
 
http://www.ietf.org/internet-drafts/draft-dutcher-enum-root-d= omain-01.txt
 
Sincerely,
 
Kevin........
 
------_=_NextPart_001_01C1BBAF.B62259E0-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 22 09:58:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04512 for ; Fri, 22 Feb 2002 09:58:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27062 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 09:58:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26446; Fri, 22 Feb 2002 09:50:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26414 for ; Fri, 22 Feb 2002 09:50:15 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04120 for ; Fri, 22 Feb 2002 09:50:09 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id GAA21591; Fri, 22 Feb 2002 06:49:41 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 06:49:41 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B014B1017@opwinex01.corp.illuminet.com> From: Kevin McCandless To: "'enum@ietf.org'" Cc: "'bdutcher@verisign.com'" Date: Fri, 22 Feb 2002 06:49:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBB0.282F9610" Subject: [Enum] FW: ENUM individual draft on root domain. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@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. ------_=_NextPart_001_01C1BBB0.282F9610 Content-Type: text/plain; charset="iso-8859-1" resending to correct email address. -----Original Message----- From: Kevin McCandless Sent: Friday, February 22, 2002 8:46 AM To: 'enum@ietf.org' Cc: 'bdutcher@versigin.com' Subject: ENUM individual draft on root domain. Here is the link to the updated draft from Bill and myself on ENUM root domain. We wanted to share our opinions and thoughts with you on this issue. You can find the updated draft at the URL below. http://www.ietf.org/internet-drafts/draft-dutcher-enum-root-domain-01.txt Sincerely, Kevin........ ------_=_NextPart_001_01C1BBB0.282F9610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
resending to correct email = address.
 
-----Original Message-----
From: Kevin McCandless=20
Sent: Friday, February 22, 2002 8:46 AM
To:=20 'enum@ietf.org'
Cc: = 'bdutcher@versigin.com'
Subject: ENUM=20 individual draft on root domain.

Here = is the link to=20 the updated draft from Bill and myself on ENUM root domain.  We = wanted to=20 share our opinions and thoughts with you on this = issue.
 
You = can find the=20 updated draft at the URL below.
 
http://www.ietf.org/internet-drafts/draft-dutcher-enum-root-d= omain-01.txt
 
Sincerely,
 
Kevin........
 
------_=_NextPart_001_01C1BBB0.282F9610-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 22 10:01:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04692 for ; Fri, 22 Feb 2002 10:01:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27732 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 10:01:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26630; Fri, 22 Feb 2002 09:53:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26603 for ; Fri, 22 Feb 2002 09:53:19 -0500 (EST) Received: from localhost ([218.51.122.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04260 for ; Fri, 22 Feb 2002 09:53:14 -0500 (EST) Message-Id: <200202221453.JAA04260@ietf.org> Reply-To: young@kimcad.co.kr From: 한국인텔리마케팅 To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 22 Feb 2002 23:26:28 +0900 Subject: [Enum] [광고]국산캐드 캐디안 특별가 가정용(학생용)정품보급 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org 개인용(020218)

 

국산캐드 캐디안 특별가 가정용(학생용)정품보급 

■ 특징

- AutoCAD와 동일한 명령어

- AutoCAD의 모든 버전과 양방향 호환

- AutoCAD와 흡사한 아이콘 사용

■ 개발사(인텔리코리아) 소개

- (매일경제신문,중기청,산자부)우수벤처로 선정(2001년)

- (전국경제인연합회,국제산업협력재단) 유망벤처 20개 기업에 선정(2001년)

- (한국경제신문)벤처리더 50인에 선정(2001년)

- (산업자원부)산업협력대회 대통령상 수상(2000년)

- (정보통신부)S/W 공모대전 우수상 수상(2000년)

■ 상업용(소비자가 90만원)과 다른점

-VBA(Visual Basic Application)제외

-이미지 삽입기능 제외

-3D 기능 제한적임.

■ 평가판(체험판)은

평가판은 다음,라이코스,엠파스,드림위즈,쉐어웨어코리아(아이누리),한미르,심마니,보물섬,넷츠고,

휴먼컴 등의 자료실 그래픽 관련에서 다운로드 하실 수 있습니다.

http://www.kimcad.co.kr/download/cadian_web_eval.exe

■ 제품별 가격표

제품명

제품구성

가  격

비  고

CADian LT

CD+교재1권

25,000원

AutoCAD 대응

CADian LT ARCH

CD+교재2권

45,000원

건축설계용

CADian LT MECH

CD+교재2권

60,000원

기계부품5,000만개 내장

※ ESD로 구매하시면 5,000원 할인.

■ 구입방법

①'한국인텔리마케팅'의 홈페이지 www.kimcad.co.kr의 가정용 라이선스 에서 신청

②한글과컴퓨터,휴먼컴,보물섬,쉐어웨어코리아(아이누리) ,소프트비젼-MSshop 등의 인터넷 쇼핑

   몰 중 ESD 또는 다운로드 샵  코너에서 구입

http://www.koreasoft.com/viewSoftware.jsp?pcode=ESD1005260

※ESD : Electronic Software Delivery(다운로드로 구매)

③서울시내 대형서점(종로,영풍,코엑스의 서울문고 등)에서 구입

구입문의:한국인텔리마케팅
http://www.kimcad.co.kr
E-Mail : young@kimcad.co.kr
전화:(02)6436-3685, 017-266-3619
담당자 : 김진항

_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 22 10:44:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06574 for ; Fri, 22 Feb 2002 10:44:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00374 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 10:44:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29751; Fri, 22 Feb 2002 10:35:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29717 for ; Fri, 22 Feb 2002 10:35:56 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06135 for ; Fri, 22 Feb 2002 10:35:52 -0500 (EST) Received: from [193.118.192.40] ([193.118.192.40] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062744 for ; Fri, 22 Feb 2002 15:35:54 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <1C1EEC765F843E44996971A80682118B014B1016@opwinex01.corp.illuminet.com> References: <1C1EEC765F843E44996971A80682118B014B1016@opwinex01.corp.illuminet.com> Date: Fri, 22 Feb 2002 15:35:51 +0000 To: "'enum@ietf.org'" From: Lawrence Conroy Subject: Re: [Enum] ENUM individual draft on root domain. Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 6:46 am -0800 22/2/02, Kevin McCandless wrote: >Here is the link to the updated draft from Bill and myself on ENUM >root domain. We wanted to share our opinions and thoughts with you >on this issue. > >http://www.ietf.org/internet-drafts/draft-dutcher-enum-root-domain-01.txt Oh no, not more root canal work :) As a European, Just wanted to share mine. BR, L -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 22 10:46:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06638 for ; Fri, 22 Feb 2002 10:46:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00444 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 10:46:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29885; Fri, 22 Feb 2002 10:37:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29855 for ; Fri, 22 Feb 2002 10:37:29 -0500 (EST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06237 for ; Fri, 22 Feb 2002 10:37:26 -0500 (EST) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id g1MFbKp12085; Fri, 22 Feb 2002 15:37:20 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.35 #1) id 16eHl7-000PcV-00; Fri, 22 Feb 2002 15:37:17 +0000 Date: Fri, 22 Feb 2002 15:37:17 +0000 From: "Clive D.W. Feather" To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: enum@ietf.org Subject: Re: [Enum] 2916bis Message-ID: <20020222153717.GL38561@finch-staff-1.demon.net> References: <7698459.1014326952@localhost> <7731583.1014327504@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <7731583.1014327504@localhost> User-Agent: Mutt/1.3.27i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA29856 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik F�ltstr�m said: > Ok, I see myself that the examples are wrong. I forgot to change them. The > correct ones should be: > > > IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:info@tele2.se!" . > IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:info@tele2.se!" . > > IN NAPTR 10 10 "u" "E2U+sip" "!^.*$!sip:paf@swip.net!" . > IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:paf@swip.net!" . > IN NAPTR 102 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . Should that last one really have two dollar signs ? -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | NOTE: fax number change _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Feb 22 10:47:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06769 for ; Fri, 22 Feb 2002 10:47:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00611 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 10:47:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00063; Fri, 22 Feb 2002 10:39:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00037 for ; Fri, 22 Feb 2002 10:39:10 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06336 for ; Fri, 22 Feb 2002 10:39:07 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1MFbf187298; Fri, 22 Feb 2002 07:37:41 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202221537.g1MFbf187298@nic-naa.net> To: enum@ietf.org cc: brunner@nic-naa.net Subject: Re: [Enum] ENUM individual draft on root domain. Date: Fri, 22 Feb 2002 10:37:40 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I'm having a bad ID week. First it was draft-regretable-junk-and-immigration-policy-00.txt, in which string value pairs were introduced as "new parameters" to a provisioning protocol that is XML-based, no doubt because schemas and validation tools are useless clutter, namespaced mechanism scope hadn't been invented, and some state's policy needed to see the light of day with an ISOC copyright as an IETF ID. Today it is draft-holy-sed-script-00.txt, in which s/\.arpa/\.foo/ is retroactively applied to 2916, no doubt because there really is a value proposition in a spelling mistake, and some state's policy needs to see the light of day with an ISOC copyright as an IETF ID. The practice of vanity publication of "Internet Drafts" as corporate posture to be "spun" before some clue-limited regulatory body, is an abuse of this body. Seriously bad memos (Simon Higgs' comes to mind) have been unpublished. Both of these are reasonable candidates for de-listing. I'd like to see some abuses of this body moved to historic status. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 11:08:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07791 for ; Fri, 22 Feb 2002 11:08:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02154 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 11:08:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01192; Fri, 22 Feb 2002 10:59:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01160 for ; Fri, 22 Feb 2002 10:59:31 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07327 for ; Fri, 22 Feb 2002 10:59:27 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1MFsGI2010851; Fri, 22 Feb 2002 10:54:16 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1MFsGOf010850; Fri, 22 Feb 2002 10:54:16 -0500 (EST) Date: Fri, 22 Feb 2002 10:54:16 -0500 From: Michael Mealling To: "Clive D.W. Feather" Cc: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , enum@ietf.org Subject: Re: [Enum] 2916bis Message-ID: <20020222105416.R8392@bailey.dscga.com> Reply-To: Michael Mealling References: <7698459.1014326952@localhost> <7731583.1014327504@localhost> <20020222153717.GL38561@finch-staff-1.demon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20020222153717.GL38561@finch-staff-1.demon.net> User-Agent: Mutt/1.3.22.1i Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit On Fri, Feb 22, 2002 at 03:37:17PM +0000, Clive D.W. Feather wrote: > Patrik F�ltstr�m said: > > Ok, I see myself that the examples are wrong. I forgot to change them. The > > correct ones should be: > > > > > > IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:info@tele2.se!" . > > IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:info@tele2.se!" . > > > > IN NAPTR 10 10 "u" "E2U+sip" "!^.*$!sip:paf@swip.net!" . > > IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:paf@swip.net!" . > > IN NAPTR 102 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . > > Should that last one really have two dollar signs ? You're right.... this is the correct record.... I apologize for the many typos. I had this, CNRP and DDDS documents all open at the same time. You should be gratefull that I didn't start sticking XML in here! ;-) IN NAPTR 102 10 "u" "E2U+tel" "!^(.*)$!tel:\1!" . -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 11:15:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08151 for ; Fri, 22 Feb 2002 11:15:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02832 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 11:16:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02016; Fri, 22 Feb 2002 11:07:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01924 for ; Fri, 22 Feb 2002 11:07:11 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07726 for ; Fri, 22 Feb 2002 11:07:08 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1MG60218200 for ; Fri, 22 Feb 2002 11:06:24 -0500 Message-Id: <5.1.0.14.2.20020222091541.0219c408@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Feb 2002 11:07:52 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-dutcher-enum-root-domain-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org The actual Announce notice .... of the personal ID noted earlier. >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-dutcher-enum-root-domain-01.txt >Date: Fri, 22 Feb 2002 06:20:19 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : ENUM Root Domain > Author(s) : W. Dutcher, K. McCandless > Filename : draft-dutcher-enum-root-domain-01.txt > Pages : > Date : 21-Feb-02 > >RFC 2916 specifies that the domain e164.arpa is the root >domain for the DNS storage for NAPTR records for ENUMs. >This document proposes that the root domain referenced in >RFC 2916 be changed from e164.arpa to a generic domain, such >as e164.foo. This would give developers of ENUM applica- >tions a greater degree of flexibility in configuring DNS >structures for ENUM. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-dutcher-enum-root-domain-01.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-dutcher-enum-root-domain-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-dutcher-enum-root-domain-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20020221154630.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-dutcher-enum-root-domain-01.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 11:16:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08182 for ; Fri, 22 Feb 2002 11:16:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02871 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 11:16:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02095; Fri, 22 Feb 2002 11:07:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02062 for ; Fri, 22 Feb 2002 11:07:37 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07755 for ; Fri, 22 Feb 2002 11:07:32 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1MG6P218210 for ; Fri, 22 Feb 2002 11:06:49 -0500 Message-Id: <5.1.0.14.2.20020222091556.04182308@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Feb 2002 10:54:14 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-zmolek-enum-pointer-00.txt >Date: Fri, 22 Feb 2002 06:20:26 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : ENUM Service Resolution Pointer > Author(s) : A. Zmolek > Filename : draft-zmolek-enum-pointer-00.txt > Pages : 6 > Date : 21-Feb-02 > >Current notions of service field tags in ENUM NAPTR records would >frame the service exposure problem as a tradeoff between the privacy >and heft involved in revealing detailed service information on the >one hand or the arbitrary constraint of such information on the >other. This draft suggests an alternative approach that keeps NAPTR >record size small, places service exposure policy and presence >capabilities in the hands of the ENUM registrant where it belongs, >and minimizes impact to the ENUM registrar and their respective DNS >architecture. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-zmolek-enum-pointer-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-zmolek-enum-pointer-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-zmolek-enum-pointer-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20020221154643.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-zmolek-enum-pointer-00.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 11:22:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08477 for ; Fri, 22 Feb 2002 11:22:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03339 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 11:22:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02596; Fri, 22 Feb 2002 11:13:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02567 for ; Fri, 22 Feb 2002 11:13:21 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08034 for ; Fri, 22 Feb 2002 11:13:18 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1MG7oI2010896; Fri, 22 Feb 2002 11:07:50 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1MG7onh010895; Fri, 22 Feb 2002 11:07:50 -0500 (EST) Date: Fri, 22 Feb 2002 11:07:49 -0500 From: Michael Mealling To: Eric Brunner-Williams in Portland Maine Cc: enum@ietf.org Subject: Re: [Enum] ENUM individual draft on root domain. Message-ID: <20020222110749.S8392@bailey.dscga.com> Reply-To: Michael Mealling References: <200202221537.g1MFbf187298@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202221537.g1MFbf187298@nic-naa.net> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Fri, Feb 22, 2002 at 10:37:40AM -0500, Eric Brunner-Williams in Portland Maine wrote: > I'm having a bad ID week. You're not the only one.... > First it was draft-regretable-junk-and-immigration-policy-00.txt, in which > string value pairs were introduced as "new parameters" to a provisioning > protocol that is XML-based, no doubt because schemas and validation tools > are useless clutter, namespaced mechanism scope hadn't been invented, and > some state's policy needed to see the light of day with an ISOC copyright > as an IETF ID. > > Today it is draft-holy-sed-script-00.txt, in which s/\.arpa/\.foo/ is > retroactively applied to 2916, no doubt because there really is a value > proposition in a spelling mistake, and some state's policy needs to see > the light of day with an ISOC copyright as an IETF ID. I had some input into this document and to be fair it is making a point that isn't to divisive. Yes, it could have possibly been made as a point on the mailing list but this way its raised the point a little higher. There's nothing wrong with that. > The practice of vanity publication of "Internet Drafts" as corporate posture > to be "spun" before some clue-limited regulatory body, is an abuse of this > body. Seriously bad memos (Simon Higgs' comes to mind) have been unpublished. > Both of these are reasonable candidates for de-listing. I'd like to see some > abuses of this body moved to historic status. There's a tradeoff here. In many situations the IETF has a long tradition of using drafts to contribute to the debate. If someone has enough conviction behind their idea or point to go through the trouble of putting it in ID form and having it in the repository then IMHO that's a good thing. Having a document like this in the repository doesn't hurt anyone (especially if it is NOT on the WG's agenda). In the new comers orientation we tell new IETF participants that there are two ways to contribute to a WG: participate on the mailing list or publish an ID. Bill and Kevin are new to this whole IETF process as are many on this list. When they first came here they were told that this is the way to add to the discussion in a really substantive way. Heck, the IESG has long had a semi-formal policy that if it ain't in the repository then it simply doesn't exist as far as they're concerned. Did this document warrant being on the WG's list of documents? No. But does it deserve derision for being submitted as an ID? No. And that goes for any other document in the repository... If the issue is 'vanity publication of "Internet Drafts" then we need to ban the entire practice of April Fools drafts... Its just a draft Eric.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 11:47:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09979 for ; Fri, 22 Feb 2002 11:47:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05471 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 11:47:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04690; Fri, 22 Feb 2002 11:38:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04656 for ; Fri, 22 Feb 2002 11:38:23 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09356 for ; Fri, 22 Feb 2002 11:38:20 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1MGar187502; Fri, 22 Feb 2002 08:36:53 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202221636.g1MGar187502@nic-naa.net> To: Michael Mealling cc: Eric Brunner-Williams in Portland Maine , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] ENUM individual draft on root domain. In-Reply-To: Your message of "Fri, 22 Feb 2002 11:07:49 EST." <20020222110749.S8392@bailey.dscga.com> Date: Fri, 22 Feb 2002 11:36:53 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > Heck, the IESG has long had a semi-formal policy that if it ain't > in the repository then it simply doesn't exist as far as they're concerned. From the WG document change control perspective, the IESG doesn't exist until the memo is WG LC'd. WG start-up, shut-down, and other process exceptions ignored. Symmetry is good. > Did this document warrant being on the WG's list of documents? No. But > does it deserve derision for being submitted as an ID? No. And that goes > for any other document in the repository... Not all ideas are created equal. In particular, the cardinality of drafts that have been removed for reasons other than author withdrawal and expiry is greater than zero. A whole ID for an application of sed with a pattern space of four characters and a substitute string of three is ... an ID for seven magnificent characters. > If the issue is 'vanity publication of "Internet Drafts" then we need > to ban the entire practice of April Fools drafts... Now that is something I'd like to see you suggest during plenary open-mic time, the response would be entertaining. Bring band aides and an analgesic, and enough of the latter to share. EOT for me. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 12:01:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10988 for ; Fri, 22 Feb 2002 12:01:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA07897 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 12:02:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05963; Fri, 22 Feb 2002 11:53:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05934 for ; Fri, 22 Feb 2002 11:53:19 -0500 (EST) Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10456 for ; Fri, 22 Feb 2002 11:53:11 -0500 (EST) Received: from 1cust162.tnt1.winchester.va.da.uu.net ([67.201.229.162] helo=z000679) by swan.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 16eIwW-00059B-00; Fri, 22 Feb 2002 08:53:09 -0800 Reply-To: From: "Mark Harris" To: "Eric Brunner-Williams in Portland Maine" , Subject: RE: [Enum] ENUM individual draft on root domain. Date: Fri, 22 Feb 2002 11:53:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200202221537.g1MFbf187298@nic-naa.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Hi Eric: In response to your comment: >Today it is draft-holy-sed-script-00.txt, in which s/\.arpa/\.foo/ is >retroactively applied to 2916, no doubt because there really is a value >proposition in a spelling mistake, and some state's policy needs to see >the light of day with an ISOC copyright as an IETF ID. Actually, the ".arpa" in 2916 should be changed to ".foo", for a few good reasons: 1) The whole ".int" vs. ".arpa" debate. 2) Some people seem to believe that if ".arpa" is changed to ".int" or even "e164.com", that it is no longer using the ENUM protocol, which is an obvious misunderstanding. I don't think that anyone on this list would argue that e164.com or even enum.org isn't using the ENUM protocol, but some, in other forums have tried to say, that if it isn't in ".arpa" than it's not the ENUM standard. Making that simple change could allow anyone to take advantage of the ENUM protocol; Private or Public, ITU-level, Country-level or even corporate implementers, would then, if fact, be using the ENUM standard. Have A Great Day! Mark Mark Harris www.EnumForums.org _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 12:19:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12057 for ; Fri, 22 Feb 2002 12:19:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08829 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 12:19:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08411; Fri, 22 Feb 2002 12:11:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08380 for ; Fri, 22 Feb 2002 12:11:13 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11469 for ; Fri, 22 Feb 2002 12:11:09 -0500 (EST) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA15271 for ; Fri, 22 Feb 2002 12:10:42 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <1SLJR6R4>; Fri, 22 Feb 2002 12:09:28 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B6FB@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Date: Fri, 22 Feb 2002 12:09:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > -----Original Message----- > From: Mark Harris [mailto:mark.harris@enumforums.org] > Sent: Friday, February 22, 2002 11:53 AM > To: Eric Brunner-Williams in Portland Maine; enum@ietf.org > Subject: RE: [Enum] ENUM individual draft on root domain. > > > Hi Eric: > > In response to your comment: > >Today it is draft-holy-sed-script-00.txt, in which s/\.arpa/\.foo/ is > >retroactively applied to 2916, no doubt because there really > is a value > >proposition in a spelling mistake, and some state's policy > needs to see > >the light of day with an ISOC copyright as an IETF ID. > > Actually, the ".arpa" in 2916 should be changed to ".foo", for a few > good reasons: I've had an off-list conversation with both 2916bis editors (Patrik and Michael) asking a similar question: would it be possible to make 2916bis completely policy/implementation neutral (basically removing mention of a specific rooting point in the DNS hierarchy), and perhaps writing a second e164.arpa implementation profile document? In the provreg WG we had many interesting discussions surrounding domain name registration policy vs. policy-neutral protocol, and I personally found it very helpful to try to separate the two wherever possible. A similar split _might_ help us focus on technical protocol issues in 2916bis rather than perceived policy issues. -Scott- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 13:00:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13972 for ; Fri, 22 Feb 2002 13:00:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11051 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 13:00:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10403; Fri, 22 Feb 2002 12:51:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10374 for ; Fri, 22 Feb 2002 12:51:48 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13569 for ; Fri, 22 Feb 2002 12:51:45 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16eJop-000MWe-00; Fri, 22 Feb 2002 09:49:15 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Mark Harris" Cc: "Eric Brunner-Williams in Portland Maine" , Subject: RE: [Enum] ENUM individual draft on root domain. References: <200202221537.g1MFbf187298@nic-naa.net> Message-Id: Date: Fri, 22 Feb 2002 09:49:15 -0800 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > Actually, the ".arpa" in 2916 should be changed to ".foo", for a few > good reasons: it should not. see IAB decision. > 1) The whole ".int" vs. ".arpa" debate. there is no debate. it was a consensus decision. not everyone agreed. that's life. > 2) Some people seem to believe that if ".arpa" is changed to ".int" or > even "e164.com", that it is no longer using the ENUM protocol, > which is an obvious misunderstanding. no. enum is specifically the use of dns in the e164.arpa domain. e164.co.ke, or any other zone than e164.arpa, is use of the dns for something else. but we do have sympathy for your political and commercial interests. randy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 13:26:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15038 for ; Fri, 22 Feb 2002 13:26:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12531 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 13:26:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11868; Fri, 22 Feb 2002 13:18:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11837 for ; Fri, 22 Feb 2002 13:17:57 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14715 for ; Fri, 22 Feb 2002 13:17:53 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1MIDkI2011307; Fri, 22 Feb 2002 13:13:46 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1MIDjWk011306; Fri, 22 Feb 2002 13:13:45 -0500 (EST) Date: Fri, 22 Feb 2002 13:13:45 -0500 From: Michael Mealling To: "Hollenbeck, Scott" Cc: enum@ietf.org Subject: Re: [Enum] ENUM individual draft on root domain. Message-ID: <20020222131345.U8392@bailey.dscga.com> Reply-To: Michael Mealling References: <3CD14E451751BD42BA48AAA50B07BAD60189B6FB@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B6FB@vsvapostal3.bkup6> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Fri, Feb 22, 2002 at 12:09:51PM -0500, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: Mark Harris [mailto:mark.harris@enumforums.org] > > Sent: Friday, February 22, 2002 11:53 AM > > To: Eric Brunner-Williams in Portland Maine; enum@ietf.org > > Subject: RE: [Enum] ENUM individual draft on root domain. > > > > > > Hi Eric: > > > > In response to your comment: > > >Today it is draft-holy-sed-script-00.txt, in which s/\.arpa/\.foo/ is > > >retroactively applied to 2916, no doubt because there really > > is a value > > >proposition in a spelling mistake, and some state's policy > > needs to see > > >the light of day with an ISOC copyright as an IETF ID. > > > > Actually, the ".arpa" in 2916 should be changed to ".foo", for a few > > good reasons: > > I've had an off-list conversation with both 2916bis editors (Patrik and > Michael) asking a similar question: would it be possible to make 2916bis > completely policy/implementation neutral (basically removing mention of a > specific rooting point in the DNS hierarchy), and perhaps writing a second > e164.arpa implementation profile document? In the provreg WG we had many > interesting discussions surrounding domain name registration policy vs. > policy-neutral protocol, and I personally found it very helpful to try to > separate the two wherever possible. A similar split _might_ help us focus > on technical protocol issues in 2916bis rather than perceived policy issues. BUT.... RFC 2916 defined two things (in much the same way that RFC 1035 did): the ENUM _system_ and a protocol. In much the same way that many people have private, enterprise level DNS namespaces, there can be private uses of the protocol that RFC 2916 defined. But the questions is: are those private uses part of the ENUM _system_? Is your private, enterpise DNS namespace part of the DNS system? I hope not. It would kind of defeat the purpose. So, be clear: are we talking about the protocol or the system? There never has been anything stopping anyone from using the techniques laid out in 2916 (or 1035) within their own administrative domain. The only thing you shouldn't do is be claiming that your private use of the protocol also means that you are part of the _system_. Frankly, I don't really care what some one does as part of their internal or proprietary system. The _utility_ comes from the _system_ and the fact that I can interoperate with it and rely on the fact that it's run according to the policies and procedures of the namespace. If that weren't the case then everyone would be using every DNS root someone cared to setup. The utility of DNS was never the protocol, its the agreement that everyone made to use the same root.... Here's my question in response: what is stopping someone from using the same technique in 2916 with some other root? Why does it matter that 2916bis specify that its possible to do so? RFC 1035 never said something like that and nobody ever suggested that it kept them from setting up their own private domain-name spaces.. -MM -- -------------------------------------------------------------------------------- Michael Mealling | mailto:michael@research.netsol.com Advanced Naming Research Manager | go:Michael Mealling Verisign Applied Research | urn:pin:1 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 13:28:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15159 for ; Fri, 22 Feb 2002 13:28:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12696 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 13:28:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12066; Fri, 22 Feb 2002 13:19:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12034 for ; Fri, 22 Feb 2002 13:19:41 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14752 for ; Fri, 22 Feb 2002 13:19:39 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1MIHZ221212; Fri, 22 Feb 2002 13:17:59 -0500 Message-Id: <5.1.0.14.2.20020222131212.02498368@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Feb 2002 13:19:42 -0500 To: "Hollenbeck, Scott" , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] ENUM individual draft on root domain. In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B6FB@vsvapostal3.bkup6 > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > >I've had an off-list conversation with both 2916bis editors (Patrik and >Michael) asking a similar question: would it be possible to make 2916bis >completely policy/implementation neutral (basically removing mention of a >specific rooting point in the DNS hierarchy), and perhaps writing a second >e164.arpa implementation profile document? In the provreg WG we had many >interesting discussions surrounding domain name registration policy vs. >policy-neutral protocol, and I personally found it very helpful to try to >separate the two wherever possible. A similar split _might_ help us focus >on technical protocol issues in 2916bis rather than perceived policy issues. IMHO the answer to that is NO. The two issues of domain and implementation are totally inseparable as it is in the case of other core infrastructure issues such as IPv6.arpa. The suggestion, however thoughtful and well meaning, is a Trojan horse for the desire of some to stop the deployment of e164.arpa. Now if we can get back to our regularly scheduled programming.... >-Scott- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 13:32:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15401 for ; Fri, 22 Feb 2002 13:32:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13568 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 13:32:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12288; Fri, 22 Feb 2002 13:23:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12258 for ; Fri, 22 Feb 2002 13:23:56 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14948 for ; Fri, 22 Feb 2002 13:23:54 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA18552; Fri, 22 Feb 2002 13:23:20 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <15YH4JM8>; Fri, 22 Feb 2002 13:23:20 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B6FD@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Date: Fri, 22 Feb 2002 13:23:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > -----Original Message----- > From: Richard Shockey [mailto:rich.shockey@NeuStar.com] > Sent: Friday, February 22, 2002 1:20 PM > To: Hollenbeck, Scott; enum@ietf.org > Subject: RE: [Enum] ENUM individual draft on root domain. > > > > The suggestion, however thoughtful and well meaning, is a Trojan horse for > the desire of some to stop the deployment of e164.arpa. Completely false. I plainly suggested development of a companion e164.arpa implementation profile to _support_ deployment in e164.arpa. You might disagree with the utility of the separation, but please don't cast aspersions where they don't belong. -Scott- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 13:32:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15427 for ; Fri, 22 Feb 2002 13:32:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13585 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 13:32:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12332; Fri, 22 Feb 2002 13:24:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12301 for ; Fri, 22 Feb 2002 13:24:04 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14950 for ; Fri, 22 Feb 2002 13:24:01 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1MII2I2011320; Fri, 22 Feb 2002 13:18:02 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1MIHbeP011319; Fri, 22 Feb 2002 13:17:37 -0500 (EST) Date: Fri, 22 Feb 2002 13:17:37 -0500 From: Michael Mealling To: Randy Bush Cc: Mark Harris , Eric Brunner-Williams in Portland Maine , enum@ietf.org Subject: Re: [Enum] ENUM individual draft on root domain. Message-ID: <20020222131737.V8392@bailey.dscga.com> Reply-To: Michael Mealling References: <200202221537.g1MFbf187298@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Fri, Feb 22, 2002 at 09:49:15AM -0800, Randy Bush wrote: > > Actually, the ".arpa" in 2916 should be changed to ".foo", for a few > > good reasons: > > it should not. see IAB decision. PLEASE re-read the latest version. This entire thread has completely misunderstood the purpose of that document..... > > 1) The whole ".int" vs. ".arpa" debate. > > there is no debate. it was a consensus decision. not everyone agreed. > that's life. > > > 2) Some people seem to believe that if ".arpa" is changed to ".int" or > > even "e164.com", that it is no longer using the ENUM protocol, > > which is an obvious misunderstanding. > > no. enum is specifically the use of dns in the e164.arpa domain. > > e164.co.ke, or any other zone than e164.arpa, is use of the dns for > something else. The only thing that draft is saying is that any udpate to RFC2916 should be cognizant of the debate and that the IAB in conjunction with the ITU might change their mind in the future. It never says that it should be something beyond what the IAB/ITU says it is or that it should be a multi-valued property. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 13:54:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16451 for ; Fri, 22 Feb 2002 13:54:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15001 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 13:54:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14375; Fri, 22 Feb 2002 13:45:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14344 for ; Fri, 22 Feb 2002 13:45:38 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16054 for ; Fri, 22 Feb 2002 13:45:35 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA01676; Fri, 22 Feb 2002 19:45:03 +0100 (MET) Date: Fri, 22 Feb 2002 19:28:59 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Brandner Rudolf cc: enum@ietf.org Subject: Re: AW: [Enum] 2916bis - more initial review Message-ID: <12449774.1014406139@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-22 13.19 +0100 Brandner Rudolf wrote: > > line 438-440: Could not parse that sentence, maybe it is misformed or > maybe due to the fact that my native language is not English error> I am from Sweden, so my native language is not English either. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 13:54:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16504 for ; Fri, 22 Feb 2002 13:54:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15069 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 13:54:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14413; Fri, 22 Feb 2002 13:46:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14389 for ; Fri, 22 Feb 2002 13:46:15 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16096 for ; Fri, 22 Feb 2002 13:46:12 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA01693; Fri, 22 Feb 2002 19:45:10 +0100 (MET) Date: Fri, 22 Feb 2002 19:44:50 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Hollenbeck, Scott" , enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Message-ID: <12506879.1014407090@localhost> In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B6FB@vsvapostal3.bkup6> References: <3CD14E451751BD42BA48AAA50B07BAD60189B6FB@vsvapostal3.bkup6> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-22 12.09 -0500 "Hollenbeck, Scott" wrote: > I've had an off-list conversation with both 2916bis editors (Patrik and > Michael) asking a similar question: would it be possible to make 2916bis > completely policy/implementation neutral (basically removing mention of a > specific rooting point in the DNS hierarchy), and perhaps writing a second > e164.arpa implementation profile document? ...and the outcome of that discussion is that the document will not be split. This is also checked with our Area Directors. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 13:55:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16579 for ; Fri, 22 Feb 2002 13:55:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15197 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 13:55:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14541; Fri, 22 Feb 2002 13:46:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14495 for ; Fri, 22 Feb 2002 13:46:52 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16142 for ; Fri, 22 Feb 2002 13:46:49 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA01683; Fri, 22 Feb 2002 19:45:07 +0100 (MET) Date: Fri, 22 Feb 2002 19:42:10 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: mark.harris@enumforums.org, Eric Brunner-Williams in Portland Maine , enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Message-ID: <12497237.1014406930@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-22 11.53 -0500 Mark Harris wrote: > Actually, the ".arpa" in 2916 should be changed to ".foo", for a few > good reasons: No. The domain name e164.arpa is decided by the IAB, and what is in use. Please see relevant documents from IAB talking about this issue. > 2) Some people seem to believe that if ".arpa" is changed to ".int" or > even "e164.com", that it is no longer using the ENUM protocol, > which is an obvious misunderstanding. If one is not using e164.arpa you are not following RFC 2916, and therefore you are not compliant to the ENUM standard. Not e164.arpa, not ENUM. Full stop. See section 1.2 in 2916bis. paf -- co-chair of the enum wg _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 14:03:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17012 for ; Fri, 22 Feb 2002 14:03:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16475 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 14:03:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15054; Fri, 22 Feb 2002 13:54:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15025 for ; Fri, 22 Feb 2002 13:54:33 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16486 for ; Fri, 22 Feb 2002 13:54:30 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1MIqs187994; Fri, 22 Feb 2002 10:52:54 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202221852.g1MIqs187994@nic-naa.net> To: "Hollenbeck, Scott" cc: enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] ENUM individual draft on root domain. In-Reply-To: Your message of "Fri, 22 Feb 2002 12:09:51 EST." <3CD14E451751BD42BA48AAA50B07BAD60189B6FB@vsvapostal3.bkup6> Date: Fri, 22 Feb 2002 13:52:54 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Afternoon Scott, > ... In the provreg WG we had many > interesting discussions surrounding domain name registration policy vs. > policy-neutral protocol ... Yup. But, none hinged upon the existance, or inexistance, of some particular namespace, and all of the implementors (honestly, I can't think of a single alternate rooter writing a line) working in the ICANN (nee IANA) namespace. No semantics were specified which were gTLD, sTLD, or ccTLD specific, or knew about root servers (A-M or on-beyond-Zebra), though IMO we didn't do a creditable job for RIRs and LIRs -- not being specific to a particular name space isn't the same is not being name space specific. I don't think a split would help. Milage varies, honest men and women differ, etc. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 14:06:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17213 for ; Fri, 22 Feb 2002 14:06:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16713 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 14:06:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15489; Fri, 22 Feb 2002 13:58:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15458 for ; Fri, 22 Feb 2002 13:58:01 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16739 for ; Fri, 22 Feb 2002 13:57:58 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1MIu5222016; Fri, 22 Feb 2002 13:56:29 -0500 Message-Id: <5.1.0.14.2.20020222134707.01942170@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Feb 2002 13:55:05 -0500 To: "Hollenbeck, Scott" , "'Richard Shockey'" , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] ENUM individual draft on root domain. In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B6FD@vsvapostal3.bkup6 > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A > > The suggestion, however thoughtful and well meaning, is a Trojan horse for > > > the desire of some to stop the deployment of e164.arpa. > >Completely false. I plainly suggested development of a companion e164.arpa >implementation profile to _support_ deployment in e164.arpa. You might >disagree with the utility of the separation, but please don't cast >aspersions where they don't belong. Please do accept my humblest apologies ...I did not mean to suggest you personally or professionally in any way. >-Scott- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 14:16:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17599 for ; Fri, 22 Feb 2002 14:16:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17527 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 14:16:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16800; Fri, 22 Feb 2002 14:08:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16767 for ; Fri, 22 Feb 2002 14:08:02 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17266 for ; Fri, 22 Feb 2002 14:07:58 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id LAA15799; Fri, 22 Feb 2002 11:05:42 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 11:05:42 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B014B101C@opwinex01.corp.illuminet.com> From: Kevin McCandless To: "'mark.harris@enumforums.org'" , Eric Brunner-Williams in Portland Maine , enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Date: Fri, 22 Feb 2002 11:05:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Mark read the draft and understood it! Our points are two and very simple: 1) ENUM is not .arpa and to say so is allowing policy to be set in an IETF draft. ENUM can reside in any TLD. 2) We support a single zone for infrastructure reasons. All we wanted to do is separate the technical aspects of RFC2916 from the policy/political. One would think that all IETF members would want to support such an effort. To the point of 'junk', we have right to our opinion and a valid one at that. Bringing different view points to the IETF is what gives it its strength. Take that away and well you get nothing but 'junk'. K........... > -----Original Message----- > From: Mark Harris [mailto:mark.harris@enumforums.org] > Sent: Friday, February 22, 2002 10:53 AM > To: Eric Brunner-Williams in Portland Maine; enum@ietf.org > Subject: RE: [Enum] ENUM individual draft on root domain. > > > Hi Eric: > > In response to your comment: > >Today it is draft-holy-sed-script-00.txt, in which s/\.arpa/\.foo/ is > >retroactively applied to 2916, no doubt because there really > is a value > >proposition in a spelling mistake, and some state's policy > needs to see > >the light of day with an ISOC copyright as an IETF ID. > > Actually, the ".arpa" in 2916 should be changed to ".foo", for a few > good reasons: > > 1) The whole ".int" vs. ".arpa" debate. > > 2) Some people seem to believe that if ".arpa" is changed to ".int" or > even "e164.com", that it is no longer using the ENUM protocol, > which is an obvious misunderstanding. > > I don't think that anyone on this list would argue that > e164.com or even > enum.org isn't using the ENUM protocol, but some, in other forums have > tried to say, that if it isn't in ".arpa" than it's not the > ENUM standard. > > Making that simple change could allow anyone to take advantage of the > ENUM protocol; Private or Public, ITU-level, Country-level or > even corporate > implementers, would then, if fact, be using the ENUM standard. > > Have A Great Day! > > Mark > > > Mark Harris > www.EnumForums.org > > > _______________________________________________ > 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 daemon@ns.ietf.org Fri Feb 22 14:23:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17764 for ; Fri, 22 Feb 2002 14:23:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17897 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 14:23:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17334; Fri, 22 Feb 2002 14:14:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17287 for ; Fri, 22 Feb 2002 14:14:36 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17453 for ; Fri, 22 Feb 2002 14:14:34 -0500 (EST) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA20787; Fri, 22 Feb 2002 14:13:33 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <1SLJR8ZF>; Fri, 22 Feb 2002 14:13:33 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B6FE@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Date: Fri, 22 Feb 2002 14:13:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA17288 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Patrik F�ltstr�m [mailto:paf@cisco.com] > Sent: Friday, February 22, 2002 1:45 PM > To: Hollenbeck, Scott; enum@ietf.org > Subject: RE: [Enum] ENUM individual draft on root domain. > > > --On 2002-02-22 12.09 -0500 "Hollenbeck, Scott" > > wrote: > > > I've had an off-list conversation with both 2916bis editors (Patrik and > > Michael) asking a similar question: would it be possible to make 2916bis > > completely policy/implementation neutral (basically removing mention of a > > specific rooting point in the DNS hierarchy), and perhaps writing a second > > e164.arpa implementation profile document? > > ...and the outcome of that discussion is that the document will not be > split. > > This is also checked with our Area Directors. OK, then this will be EOT for me. A different suggestion given the above: please be very clear in 2916bis that the document describes a system, and not just a protocol specification. Given the first sentence in the "Status of this Memo" boilerplate from the current 2916 [1], I think it would be wise to explicitly note that there is more than an implementation-neutral protocol described in the document. Perhaps a sentence like this at the beginning of the first paragraph in the introduction: "This document includes a protocol specification and specific implementation requirements that define the ENUM system." -Scott- [1] "This document specifies an Internet standards track protocol..." _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 14:24:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17826 for ; Fri, 22 Feb 2002 14:24:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18044 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 14:24:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17505; Fri, 22 Feb 2002 14:16:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17479 for ; Fri, 22 Feb 2002 14:16:17 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17554 for ; Fri, 22 Feb 2002 14:16:14 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16eLAS-000PLn-00; Fri, 22 Feb 2002 11:15:40 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael Mealling Cc: enum@ietf.org Subject: Re: [Enum] ENUM individual draft on root domain. References: <3CD14E451751BD42BA48AAA50B07BAD60189B6FB@vsvapostal3.bkup6> <20020222131345.U8392@bailey.dscga.com> Message-Id: Date: Fri, 22 Feb 2002 11:15:40 -0800 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit there seems to be a recurring fallacy here. ENUM IS NOT A PROTOCOL. it is a convention for use of existing protocols. that convention involves o the dns protocol o the e164.arpa domain (per iab's rfc 3172) o using naptr ns rrs, and o interpreting uri results of naptr rr lookups so statements such as "keep the enum protocol but change 'arpa' to 'greed'" or "change naptr to foo" are utterly without technical meaning (other than indicating the commercial and/or political interests of those making such statements). randy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 14:37:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18430 for ; Fri, 22 Feb 2002 14:37:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA19507 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 14:37:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18300; Fri, 22 Feb 2002 14:28:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18271 for ; Fri, 22 Feb 2002 14:28:11 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18066 for ; Fri, 22 Feb 2002 14:27:51 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1MJNiI2011557; Fri, 22 Feb 2002 14:23:44 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1MJNWtc011556; Fri, 22 Feb 2002 14:23:32 -0500 (EST) Date: Fri, 22 Feb 2002 14:23:32 -0500 From: Michael Mealling To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] 2916bis initial review Message-ID: <20020222142331.Y8392@bailey.dscga.com> Reply-To: Michael Mealling References: <9886436.1014363417@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9886436.1014363417@localhost> User-Agent: Mutt/1.3.22.1i Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I'm working on these now. I hope to be done within the hour. I won't get all of these since some of them seem more like points of discussion. If you don't see a particular comment here then either I've fixed it or else I didn't have any comments since I couldn't figure out if there was supposed to be some action taken. On Fri, Feb 22, 2002 at 07:36:57AM +0100, Patrik F�ltstr�m wrote: > --On 2002-02-22 00.57 +0000 Lawrence Conroy wrote: > > > > lines 187-191 - please make up your minds - either the initial Key > > has a leading '+' sign, or it doesn't. The 1WNR converts from AUS > > (with leading '+') to a Key. In list postings, I believe that Michael > > agreed that the Key does NOT have this, so the 1ENR will NOT be null > > - it has to remove the leading '+' character. Thus AUS .NE. Key. > > > > If this is changed (as on the list), then line 208 loses the "except for > > the +", lines 212-214 go, and lines 215, 217 and 226 have the initial > > number reduced. (and the text of lines 187-188 changes, of course). > > > > If not, then please add text to explain why a Key needs the initial '+' > > character. > > > > The + should be there as part of the input to the NAPTR regexp matching, > but is not part of the domain name. This is Michaels part of the draft, and > he has to see that the WNR, AUS etc ends up being correct. > > Explanation why the leading + is there is already in section 1.2. Is that > enough for you, or do you want a pointer from the WNR section to 1.2? I've added some examples and some clarity here that I hope helps... > > > > I'm surprised at tone of the statement on lines 232-238 - this does not > > have the health warning (i.e. it's another IPV6/PKI/... and so might > > happen some time before I retire) that appears in the D3S DNS draft. > > > > I think this part is coming from some other DDDS specification Michael has > written. I.e. to me it seems like a general DDDS document spec. It should > be tuned more specifically to E2U. > > Michael? (I hope I'm getting the line numbers right. Since I'm editing the XML it'd be much easier if folks mentioned things by section number.) I'm not quiet sure what the concern is here. Obviously the SRV and A record stuff needs to be changed but is there a general problem with the paragraph beyond that? > > > > line 247 - "Database" - I think that this should be each record, or each > > NAPTR - it isn't Database. > > > > Well, "Database" is here a DDDS terminology thing. But I guess it can be > changed so people understand the sentence. I have no problem with this. Yes. The term Database is used the way the DDDS draft is using it. If you see terms capitalized then you know it has a very specific meaning. > > > > line 259-260 - This sentence needs work, as nothing exists at a Key; it > > may exist at a record indexed by a key, or returned by a subsequent > > query into the database indexed by a Key, but that is not what's stated > > here. In the D3S Algorithm draft, the term "non-terminal rule" is used. > > Why not use it here? > > > > This is for Michael. Good point... How's this: If this flag is not present then this rule is non-terminal. If a Rule is non-terminal then clients MUST use the Key produced by this Rewrite Rule as the new Key in the DDDS loop (i.e. causing the client to query for new NAPTR records at the domain-name that is the result of this Rule). > > > > The suspicious amongst us may conclude that the whole purpose of D3S and > > this update (apart from frying a few surplus brain cells) is highlighted > > on lines 546-564. You might think that, but I couldn't possibly... > > > > Well, the LDAP example existed in the previous version? > > The changes is a more crisp binding to the DDDS architecture and need for > registration mechanism of enumservices. > > Really needed things from my point of view. I could change all of the examples so they just all point to VeriSign's LDAP server! ;-) ^ /|\ | | Note: SMILEY! -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 14:37:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18455 for ; Fri, 22 Feb 2002 14:37:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA19536 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 14:37:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18378; Fri, 22 Feb 2002 14:28:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18347 for ; Fri, 22 Feb 2002 14:28:42 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18091 for ; Fri, 22 Feb 2002 14:28:39 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16eLMS-000PhF-00; Fri, 22 Feb 2002 11:28:04 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Kevin McCandless Cc: enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. References: <1C1EEC765F843E44996971A80682118B014B101C@opwinex01.corp.illuminet.com> Message-Id: Date: Fri, 22 Feb 2002 11:28:04 -0800 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > 1) ENUM is not .arpa and to say so is allowing policy to be set in an IETF > draft. true. drafts only propose protocol, policy, ... you might want to look at the *BCP*, RFC 2916, the mou in RFC 3026, etc. etc. etc. they're not drafts. randy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 14:40:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18683 for ; Fri, 22 Feb 2002 14:40:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA19981 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 14:40:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19164; Fri, 22 Feb 2002 14:31:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19061 for ; Fri, 22 Feb 2002 14:31:50 -0500 (EST) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18257 for ; Fri, 22 Feb 2002 14:31:46 -0500 (EST) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g1MJRVI2011576; Fri, 22 Feb 2002 14:27:31 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g1MJRURJ011575; Fri, 22 Feb 2002 14:27:30 -0500 (EST) Date: Fri, 22 Feb 2002 14:27:30 -0500 From: Michael Mealling To: Brandner Rudolf Cc: "'Patrik =?iso-8859-1?Q?F=E4ltstr=F6m'?=" , enum@ietf.org Subject: Re: [Enum] 2916bis - more initial review Message-ID: <20020222142730.Z8392@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Fri, Feb 22, 2002 at 01:19:29PM +0100, Brandner Rudolf wrote: > > line 438-440: Could not parse that sentence, maybe it is misformed or maybe due to the fact that my native language is not English > How does this sound: Service registrations will be published in the IANA repository and made available via the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/enum-services/". -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 14:47:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18950 for ; Fri, 22 Feb 2002 14:47:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20578 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 14:47:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19615; Fri, 22 Feb 2002 14:38:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19586 for ; Fri, 22 Feb 2002 14:38:29 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18506 for ; Fri, 22 Feb 2002 14:38:25 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1MJaS188159; Fri, 22 Feb 2002 11:36:28 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202221936.g1MJaS188159@nic-naa.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Michael Mealling cc: Brandner Rudolf , "'Patrik =?iso-8859-1?Q?F=E4ltstr=F6m'?=" , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] 2916bis - more initial review In-Reply-To: Message from Michael Mealling of "Fri, 22 Feb 2002 14:27:30 EST." <20020222142730.Z8392@bailey.dscga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Feb 2002 14:36:28 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org ... via anonymous ftp at the following URI: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 14:48:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19072 for ; Fri, 22 Feb 2002 14:48:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20740 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 14:48:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19752; Fri, 22 Feb 2002 14:39:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19723 for ; Fri, 22 Feb 2002 14:39:31 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18539 for ; Fri, 22 Feb 2002 14:39:27 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA07064; Fri, 22 Feb 2002 20:38:26 +0100 (MET) Date: Fri, 22 Feb 2002 20:36:58 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Hollenbeck, Scott" , enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Message-ID: <12694546.1014410218@localhost> In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B6FE@vsvapostal3.bkup6> References: <3CD14E451751BD42BA48AAA50B07BAD60189B6FE@vsvapostal3.bkup6> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-22 14.13 -0500 "Hollenbeck, Scott" wrote: > Given the first sentence in the "Status of this Memo" boilerplate from the > current 2916 [1] Please read the I-D for 2916bis, and come with suggestions on changes to that document if you want some changed made. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 14:58:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19589 for ; Fri, 22 Feb 2002 14:58:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21488 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 14:58:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20858; Fri, 22 Feb 2002 14:49:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20833 for ; Fri, 22 Feb 2002 14:49:48 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19146 for ; Fri, 22 Feb 2002 14:49:45 -0500 (EST) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA22742; Fri, 22 Feb 2002 14:48:14 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <1SLJR9S7>; Fri, 22 Feb 2002 14:48:14 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B701@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Date: Fri, 22 Feb 2002 14:48:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA20834 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Patrik F�ltstr�m [mailto:paf@cisco.com] > Sent: Friday, February 22, 2002 2:37 PM > To: Hollenbeck, Scott; enum@ietf.org > Subject: RE: [Enum] ENUM individual draft on root domain. > > > --On 2002-02-22 14.13 -0500 "Hollenbeck, Scott" > > wrote: > > > Given the first sentence in the "Status of this Memo" > boilerplate from the > > current 2916 [1] > > Please read the I-D for 2916bis, and come with suggestions on changes to > that document if you want some changed made. Patrik, I _did_ read the draft, and I still think the intro should have a sentence added to it (provided in my last note) to clearly explain that the document describes a _system_. Assuming 2916bis advances it's going to have the same "Status of this Memo" "protocol" boilerplate as 2916 (which I referenced only because it doesn't exist in I-Ds), though the document is more than just a protocol specification. -Scott- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 15:03:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19949 for ; Fri, 22 Feb 2002 15:03:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22367 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 15:03:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21185; Fri, 22 Feb 2002 14:54:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21154 for ; Fri, 22 Feb 2002 14:54:34 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19410 for ; Fri, 22 Feb 2002 14:54:31 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA23102; Fri, 22 Feb 2002 14:54:02 -0500 (EST) Received: from arutkowski-desk.verisign.com (ARUTKOWSKI-DESK [10.131.128.39]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15YH4MAJ; Fri, 22 Feb 2002 14:54:02 -0500 Message-Id: <5.1.0.14.2.20020222145012.0278b728@vsvapostal1.prod.netsol.com> X-Sender: trutkowski@vsvapostal1.prod.netsol.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Feb 2002 14:53:57 -0500 To: Randy Bush , Michael Mealling From: Tony Rutkowski Subject: Re: [Enum] ENUM individual draft on root domain. Cc: enum@ietf.org In-Reply-To: References: <3CD14E451751BD42BA48AAA50B07BAD60189B6FB@vsvapostal3.bkup6> <20020222131345.U8392@bailey.dscga.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 02:15 PM 2/22/2002, Randy Bush wrote: >there seems to be a recurring fallacy here. ENUM IS NOT A PROTOCOL. it is >a convention for use of existing protocols. that convention involves > o the dns protocol > o the e164.arpa domain (per iab's rfc 3172) > o using naptr ns rrs, and > o interpreting uri results of naptr rr lookups An important omission: o alleged authoritative "public" ITU/telecom provider/customer namespace This is the root of the problem. :-) --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 15:07:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20212 for ; Fri, 22 Feb 2002 15:07:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22609 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 15:07:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21373; Fri, 22 Feb 2002 14:57:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21330 for ; Fri, 22 Feb 2002 14:57:20 -0500 (EST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19503 for ; Fri, 22 Feb 2002 14:57:16 -0500 (EST) Received: from ieee.org ([68.38.219.92]) by mtaout02.icomcast.net (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GRY00C8UA2BUK@mtaout02.icomcast.net> for enum@ietf.org; Fri, 22 Feb 2002 14:56:35 -0500 (EST) Date: Fri, 22 Feb 2002 14:56:43 -0500 From: "Herman R. Silbiger" Subject: Re: [Enum] ENUM individual draft on root domain To: enum@ietf.org Message-id: <3C76A27B.2A13EE69@ieee.org> MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200202221931.OAA19118@optimus.ietf.org> Content-Transfer-Encoding: 7BIT Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7BIT > From: Randy Bush > To: Michael Mealling > Cc: enum@ietf.org > Subject: Re: [Enum] ENUM individual draft on root domain. > <20020222131345.U8392@bailey.dscga.com> > Date: Fri, 22 Feb 2002 11:15:40 -0800 > > there seems to be a recurring fallacy here. ENUM IS NOT A PROTOCOL. it is > a convention for use of existing protocols. that convention involves > o the dns protocol > o the e164.arpa domain (per iab's rfc 3172) > o using naptr ns rrs, and > o interpreting uri results of naptr rr lookups > > so statements such as "keep the enum protocol but change 'arpa' to 'greed'" > or "change naptr to foo" are utterly without technical meaning (other than > indicating the commercial and/or political interests of those making such > statements). > > randy > This is an Alice in Wonderland type of argument. "ENUM is not a protocol because I say it isn't." Perhaps is is not a unitary protocol, but it definitely is an assembly of protocols. I also don't see any problem with separating the service aspects of ENUM with the protocol description. I am quite familiar with such procedures because of my ITU experience, where this is the usual approach. Your statements about "changing 'arpa' to 'greed' and 'indicating the commercial and/or political interests of those making such statements' may equally well be applied to the proponents of the current RFC2916 and proposed RFC2916bis. Herman _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 15:11:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20343 for ; Fri, 22 Feb 2002 15:11:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22807 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 15:11:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22323; Fri, 22 Feb 2002 15:02:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22286 for ; Fri, 22 Feb 2002 15:02:21 -0500 (EST) Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19879 for ; Fri, 22 Feb 2002 15:02:18 -0500 (EST) Received: from 1cust162.tnt1.winchester.va.da.uu.net ([67.201.229.162] helo=z000679) by swan.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 16eLtV-0006Nk-00; Fri, 22 Feb 2002 12:02:13 -0800 Reply-To: From: "Mark Harris" To: "Richard Shockey" , "Hollenbeck, Scott" , Subject: RE: [Enum] ENUM individual draft on root domain. Date: Fri, 22 Feb 2002 15:02:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.0.14.2.20020222131212.02498368@popd.ix.netcom.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Hi Richard: Reply to your comment: >The suggestion, however thoughtful and well meaning, is a Trojan horse for >the desire of some to stop the deployment of e164.arpa. If 2916 became policy-neutral, by removing the mandated TLD of ".arpa", and then "allowed" other implementations, like NetNumber's e164.com (and others) to be "officially" considered ENUM, how would that be a Trojan horse for e164.arpa? Wouldn't that change, actually allow ENUM (at-large) to thrive...? Also, who are these Trojans that you are talking about above? Regards, Mark Mark Harris www.EnumForums.org _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 15:37:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22491 for ; Fri, 22 Feb 2002 15:37:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24402 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 15:37:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23651; Fri, 22 Feb 2002 15:28:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23620 for ; Fri, 22 Feb 2002 15:28:55 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22061 for ; Fri, 22 Feb 2002 15:28:52 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16eMIm-0001O9-00; Fri, 22 Feb 2002 12:28:20 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Herman R. Silbiger" Cc: enum@ietf.org Subject: Re: [Enum] ENUM individual draft on root domain References: <200202221931.OAA19118@optimus.ietf.org> <3C76A27B.2A13EE69@ieee.org> Message-Id: Date: Fri, 22 Feb 2002 12:28:20 -0800 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > This is an Alice in Wonderland type of argument. "ENUM is not a > protocol because I say it isn't." no. because it specifies no protocol. where is the description of the on-the wire data? where is the protocol state transition diagram? > Perhaps is is not a unitary protocol, but it definitely is an assembly > of protocols. it is a convention for how to use a specific set of protocols. if you don't like which protocols, or the convention of how to use them, no problem. build your own. just don't confuse people by calling it enum. > I also don't see any problem with separating the service aspects of ENUM > with the protocol description. i agree completely. you may be a bit dissapointed that removing the null set does not alter the set of the remaining elements. > I am quite familiar with such procedures because of my ITU experience i bet you are > Your statements about "changing 'arpa' to 'greed' and 'indicating the > commercial and/or political interests of those making such statements' > may equally well be applied to the proponents of the current RFC2916 and > proposed RFC2916bis. being from the itu world, you may have missed the ietf-wide consensus process that produced and ratified rfc 2916. randy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 15:57:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24401 for ; Fri, 22 Feb 2002 15:57:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25398 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 15:57:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24882; Fri, 22 Feb 2002 15:49:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24852 for ; Fri, 22 Feb 2002 15:48:59 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23116 for ; Fri, 22 Feb 2002 15:48:55 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA14417; Fri, 22 Feb 2002 21:48:09 +0100 (MET) Date: Fri, 22 Feb 2002 21:46:17 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: mark.harris@enumforums.org, Richard Shockey , "Hollenbeck, Scott" , enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Message-ID: <12944067.1014414377@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-22 15.02 -0500 Mark Harris wrote: > If 2916 became policy-neutral, by removing the mandated TLD of ".arpa", > and then "allowed" other implementations, like NetNumber's e164.com (and > others) > to be "officially" considered ENUM, how would that be a Trojan horse for > e164.arpa? > > Wouldn't that change, actually allow ENUM (at-large) to thrive...? DNS need one and only one root. You can not have two. I have earlier pointed at draft-iab-itu-enum-notes-00.txt, and I do it again... paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 15:57:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24415 for ; Fri, 22 Feb 2002 15:57:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25413 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 15:57:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24935; Fri, 22 Feb 2002 15:49:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24909 for ; Fri, 22 Feb 2002 15:49:13 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23124 for ; Fri, 22 Feb 2002 15:49:08 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA14413; Fri, 22 Feb 2002 21:48:07 +0100 (MET) Date: Fri, 22 Feb 2002 21:42:58 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Hollenbeck, Scott" , enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Message-ID: <12932162.1014414178@localhost> In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B701@vsvapostal3.bkup6> References: <3CD14E451751BD42BA48AAA50B07BAD60189B701@vsvapostal3.bkup6> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-22 14.48 -0500 "Hollenbeck, Scott" wrote: > Patrik, I _did_ read the draft, and I still think the intro should have a > sentence added to it (provided in my last note) to clearly explain that > the document describes a _system_. Assuming 2916bis advances it's going > to have the same "Status of this Memo" "protocol" boilerplate as 2916 > (which I referenced only because it doesn't exist in I-Ds), though the > document is more than just a protocol specification. Reason I asked was because I didn't understand how you wanted the text to fit together with what I say in section 1.2. I now understand you think this is not connected, or? paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 16:09:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25338 for ; Fri, 22 Feb 2002 16:09:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26612 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 16:09:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25720; Fri, 22 Feb 2002 16:00:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25689 for ; Fri, 22 Feb 2002 16:00:18 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24645 for ; Fri, 22 Feb 2002 16:00:14 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1MKwR188434; Fri, 22 Feb 2002 12:58:27 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202222058.g1MKwR188434@nic-naa.net> To: Kevin McCandless cc: "'mark.harris@enumforums.org'" , Eric Brunner-Williams in Portland Maine , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] ENUM individual draft on root domain. In-Reply-To: Your message of "Fri, 22 Feb 2002 11:05:40 PST." <1C1EEC765F843E44996971A80682118B014B101C@opwinex01.corp.illuminet.com> Date: Fri, 22 Feb 2002 15:58:27 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Kevin, ... > 1) and to say so is allowing policy to be set in an IETF > draft. No. Drafts don't set anything but themselves. Memos eventually get WG LD'd, and assuming the WG doesn't have second thoughts, IETF-wide LD'd. See 2026 or just ask the co-chairs for clue. > All we wanted to do is separate the technical aspects of RFC2916 from the > policy/political. One would think that all IETF members would want to > support such an effort. Naw. Layer violation where appropriate is fine with me. Besides, I'm not a member, don't know the secret handshake, don't have the natty pin. > To the point of 'junk', we have right to our opinion and a valid one at > that. The "junk" referred to a wonderfully clueless contribution by my former manager, his tame writer, and three innocent hostages, not the celebration of sed over sensibility you and Bill proposed. Now does having an opinion make the opinion valid by the simple act of having it? I just don't know. What do you think? Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 16:39:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26576 for ; Fri, 22 Feb 2002 16:39:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28228 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 16:39:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27418; Fri, 22 Feb 2002 16:30:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27370 for ; Fri, 22 Feb 2002 16:30:22 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26202 for ; Fri, 22 Feb 2002 16:30:18 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id QAA28549; Fri, 22 Feb 2002 16:28:59 -0500 (EST) Received: from arutkowski-desk.verisign.com (ARUTKOWSKI-DESK [10.131.128.39]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15YH435Q; Fri, 22 Feb 2002 16:28:59 -0500 Message-Id: <5.1.0.14.2.20020222161314.0279b130@vsvapostal1.prod.netsol.com> X-Sender: trutkowski@vsvapostal1.prod.netsol.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Feb 2002 16:28:55 -0500 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , mark.harris@enumforums.org, Richard Shockey , "Hollenbeck, Scott" , enum@ietf.org From: Tony Rutkowski Subject: RE: [Enum] ENUM individual draft on root domain. In-Reply-To: <12944067.1014414377@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA27371 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 03:46 PM 2/22/2002, Patrik F�ltstr�m wrote: >DNS need one and only one root. You can not have two. Hi Patrik, You might look at the RBL services arena - which is very much DNS based, which operates quite successfully on a large scale, and which functions very much like the ENUM protocol - as an example to the contrary. Different providers even return different values. You can argue that it's not desirable on some personal preference basis or comparative merits; but as to "need one" and "can not" - reality clearly argues otherwise. We're also dealing here with a DNS namespace zone, not "DNS." Providers and customers do work these things out in the marketplace without the need for governmental intervention to bless somebody's best-loved namespace. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 17:04:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27947 for ; Fri, 22 Feb 2002 17:04:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00031 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 17:04:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28816; Fri, 22 Feb 2002 16:56:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28784 for ; Fri, 22 Feb 2002 16:56:07 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27354 for ; Fri, 22 Feb 2002 16:55:51 -0500 (EST) Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id QAA00049; Fri, 22 Feb 2002 16:55:05 -0500 (EST) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <1SLJSD2F>; Fri, 22 Feb 2002 16:55:05 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B705@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Date: Fri, 22 Feb 2002 16:54:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA28785 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Patrik F�ltstr�m [mailto:paf@cisco.com] > Sent: Friday, February 22, 2002 3:43 PM > To: Hollenbeck, Scott; enum@ietf.org > Subject: RE: [Enum] ENUM individual draft on root domain. > > > Reason I asked was because I didn't understand how you wanted the text to > fit together with what I say in section 1.2. > > I now understand you think this is not connected, or? Ahh, OK. Looking at 1.2 I'll recraft the sentence a bit. How about changing this: "This document specifies how "ENUM" works, that is how to handle numbers allocated according to the ITU-T standard E.164." to this: "This document specifies the "ENUM System", that is, procedures and infrastructure that provide a service that can convert numbers allocated according to the ITU-T standard E.164 into Uniform Resource Identifiers." I think it's important to emphasize the _system_ aspect if the document is to remain structurally as-is. -Scott- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 17:06:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28007 for ; Fri, 22 Feb 2002 17:06:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00104 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 17:06:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29028; Fri, 22 Feb 2002 16:57:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28997 for ; Fri, 22 Feb 2002 16:57:36 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27506 for ; Fri, 22 Feb 2002 16:57:31 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id WAA29080; Fri, 22 Feb 2002 22:57:23 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id WAA18352; Fri, 22 Feb 2002 22:57:16 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id <1J4Q8NJF>; Fri, 22 Feb 2002 22:57:26 +0100 Message-ID: From: Brandner Rudolf To: "'Michael Mealling'" Cc: =?ISO-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "'Eric Brunner-Williams in Portland Maine'" , enum@ietf.org Subject: Re: [Enum] 2916bis - more initial review Date: Fri, 22 Feb 2002 22:56:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > On Fri, Feb 22, 2002 at 01:19:29PM +0100, Brandner Rudolf wrote: > > > > line 438-440: Could not parse that sentence, maybe it is > misformed or maybe due to the fact that my native language is > not English > > > > How does this sound: > > Service registrations will be published in the IANA > repository and made > available via the anonymous FTP directory > "ftp://ftp.isi.edu/in-notes/iana/assignments/enum-services/". > > -MM Sounds good to me, Eric's one is ok, too. Now you have the pain of choice ;^) Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 17:22:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28614 for ; Fri, 22 Feb 2002 17:22:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00899 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 17:22:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00435; Fri, 22 Feb 2002 17:14:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00404 for ; Fri, 22 Feb 2002 17:14:09 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28309 for ; Fri, 22 Feb 2002 17:14:04 -0500 (EST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g1MME1101767; Fri, 22 Feb 2002 14:14:01 -0800 (PST) From: Bill Manning Message-Id: <200202222214.g1MME1101767@boreas.isi.edu> Subject: Re: [Enum] ENUM individual draft on root domain In-Reply-To: from Randy Bush at "Feb 22, 2 12:28:20 pm" To: randy@psg.com (Randy Bush) Date: Fri, 22 Feb 2002 14:14:01 -0800 (PST) Cc: hsilbiger@ieee.org, enum@ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit % it is a convention for how to use a specific set of protocols. convention == protocol % > Your statements about "changing 'arpa' to 'greed' and 'indicating the % > commercial and/or political interests of those making such statements' % > may equally well be applied to the proponents of the current RFC2916 and % > proposed RFC2916bis. % % being from the itu world, you may have missed the ietf-wide consensus % process that produced and ratified rfc 2916. er, IESG-wide consensus, not IETF-wide. Most IETF folk don't know and were not asked. % randy --bill _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 17:56:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00035 for ; Fri, 22 Feb 2002 17:56:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03057 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 17:56:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02528; Fri, 22 Feb 2002 17:48:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02499 for ; Fri, 22 Feb 2002 17:48:06 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29688 for ; Fri, 22 Feb 2002 17:48:03 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g1MMlTp06113; Fri, 22 Feb 2002 16:47:29 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 16:47:24 -0600 Message-ID: <23309E398D84D5119D0F00306E075139ECEC81@dc02.npac.com> From: "Yu, James" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: enum@ietf.org Subject: RE: AW: [Enum] 2916bis - more initial review Date: Fri, 22 Feb 2002 16:47:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A few comments (some may have been raised by others). It is late for the first submission so they are for the next revision. James ------------------------------------------------- - Abstract, 1st sentence: The text "use of the Domain Name System (DNS) for storage of E.164 numbers" is not right. Suggest to combine the first two sentences as "This document discusses the use of the Domain Name System (DNS) for identifying available services associated with an E.164 number." - Abstract, last line: Change "discused" to "discussed." - Section 1, 2nd paragraph, 2nd line: Change "storage of E.164 numbers" to "storage of available services associated with an E.164 number." - Section 1.2, 2nd line: Change "ITU-T standard" to "ITU-T Recommendation." - Section 1.3, 1st line: There is no "priority" field in NAPTR RR. It is "order" and "preference." - Section 2.2, First Well Known Rule: The text should mention that AUS is the input . It should also mention that the output is the first valid key (which is also AUS). The explanation in the 2nd sentence does not seem to fit there. - Section 2.4, 2nd paragraph and algorithm: Since DNS is used as the "valid database," the only thing that needs to be described in this section is the "key format" (e.g., how to turn a Key into something that is valid for the database). According to the FWKR, its output, the first valid key, is again AUS. So the description should start from the first valid key, which is an E.164 number minus all non-digit characters except for the +. So step 1 can be as simple as 1. Remove the leading "+" from the first valid key. Also, it may be better if steps 2 thru 4 are changed to 2. Reverse the order of the digits. Example: 4321679864 3. Insert a dot ('.') after each digit. Example: 4.3.2.1.6.7.9.8.6.4. 4. Append the string "e164.arpa." to the end. Example: 4.3.2.1.6.7.9.8.6.4.e164.arpa. It can be debated whether there is a need to include the "." (the root) after "arpa". - Section 2.4, paragraph after step 4: Change "which produces new keys" to "which may produce new keys." - Section 2.4.2, 1st sentence: Change "Service" to "Services" at two places. - Section 2.4.2, comments in ABNF: Someone has suggested to change "protocol and rs fields" to "enumservice field." Also, change "an alphabetic" to "an alphabet." - Section 3.1.1, the last two lines: Change "transfered" to "transferred" and "tranfering" to "transfering." - Section 3.1.2: Change "exeprimental" to "experimental." - Section 4: Suggest to use the same order value but different preference values to show the preferences of the ENUM registrant. In example, "ldap" along is not sufficient to identify a particular ldap schema. Use something like "sldap" and describe that it is a specific type of ldap schema. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 18:03:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00249 for ; Fri, 22 Feb 2002 18:03:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03840 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 18:03:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02833; Fri, 22 Feb 2002 17:54:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02802 for ; Fri, 22 Feb 2002 17:54:38 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29945 for ; Fri, 22 Feb 2002 17:54:34 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA25533; Fri, 22 Feb 2002 23:54:00 +0100 (MET) Date: Fri, 22 Feb 2002 23:52:43 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Yu, James" cc: enum@ietf.org Subject: RE: AW: [Enum] 2916bis - more initial review Message-ID: <13399268.1014421963@localhost> In-Reply-To: <23309E398D84D5119D0F00306E075139ECEC81@dc02.npac.com> References: <23309E398D84D5119D0F00306E075139ECEC81@dc02.npac.com> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-22 16.47 -0600 "Yu, James" wrote: > It is late for the > first submission so they are for the next revision. And we just passed the cut-off for submissions of 00 drafts before the IETF, so no more changes will be done before the IETF. These change requests are "queued". paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 22:52:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06823 for ; Fri, 22 Feb 2002 22:52:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA14568 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 22:52:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA14233; Fri, 22 Feb 2002 22:43:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA14204 for ; Fri, 22 Feb 2002 22:43:56 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06703 for ; Fri, 22 Feb 2002 22:43:52 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1N3hp031467; Fri, 22 Feb 2002 22:43:51 -0500 Message-Id: <200202230343.g1N3hp031467@minotaur.nge.isi.edu> To: Bill Manning cc: randy@psg.com (Randy Bush), hsilbiger@ieee.org, enum@ietf.org Reply-To: mankin@isi.edu Subject: Re: [Enum] ENUM individual draft on root domain In-reply-to: Your message of Fri, 22 Feb 2002 14:14:01 -0800. <200202222214.g1MME1101767@boreas.isi.edu> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Feb 2002 22:43:51 -0500 From: Allison Mankin Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > % being from the itu world, you may have missed the ietf-wide consensus > % process that produced and ratified rfc 2916. > > er, IESG-wide consensus, not IETF-wide. Most IETF folk > don't know and were not asked. We can't tell what most IETF folk know at the end of the day, but they were* asked, via IETF Last Call. Allison _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Feb 22 22:55:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06874 for ; Fri, 22 Feb 2002 22:55:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA14659 for enum-archive@odin.ietf.org; Fri, 22 Feb 2002 22:55:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA14358; Fri, 22 Feb 2002 22:46:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA14328 for ; Fri, 22 Feb 2002 22:46:45 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06758 for ; Fri, 22 Feb 2002 22:46:41 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 50F553190C; Fri, 22 Feb 2002 19:46:13 -0800 (PST) To: Tony Rutkowski Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , mark.harris@enumforums.org, Richard Shockey , "Hollenbeck, Scott" , enum@ietf.org Subject: Re: [Enum] ENUM individual draft on root domain. In-Reply-To: Message from Tony Rutkowski of "Fri, 22 Feb 2002 16:28:55 EST." <5.1.0.14.2.20020222161314.0279b130@vsvapostal1.prod.netsol.com> Date: Fri, 22 Feb 2002 19:46:13 -0800 Message-ID: <45667.1014435973@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >>>>> "Tony" == Tony Rutkowski writes: Tony> You might look at the RBL services arena - which is very Tony> much DNS based, which operates quite successfully on a large Tony> scale, and which functions very much like the ENUM protocol Tony> - as an example to the contrary. No they don't. And RBL services are not relevant to ENUM which gets discussed here either. But we're used to your distractions and off-topic irrelevances. RBL services are discretionary: you will stll get mail (and lots more spam) if your mail system chooses not use them. If applications chooose not to perform ENUM lookups, they can't make use of ENUM based services. Not even in your parallel universes. Tony> Providers and customers do work these things out in the Tony> marketplace without the need for governmental intervention Tony> to bless somebody's best-loved namespace. Please tell us where customers and providers have created a market in reverse lookup name spaces for IPv4 or IPv6 addresses. With our without government intervention. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 23 01:56:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08870 for ; Sat, 23 Feb 2002 01:56:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA00274 for enum-archive@odin.ietf.org; Sat, 23 Feb 2002 01:56:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00085; Sat, 23 Feb 2002 01:47:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00056 for ; Sat, 23 Feb 2002 01:47:24 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08782 for ; Sat, 23 Feb 2002 01:47:23 -0500 (EST) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id WAA27273 for ; Fri, 22 Feb 2002 22:47:23 -0800 Message-Id: <5.1.0.14.2.20020222222242.02040008@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Feb 2002 22:33:33 -0800 To: enum@ietf.org From: Dave Crocker Subject: RE: [Enum] ENUM individual draft on root domain. In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B6FB@vsvapostal3.bkup6 > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 12:09 PM 2/22/2002 -0500, Hollenbeck, Scott wrote: > would it be possible to make 2916bis >completely policy/implementation neutral (basically removing mention of a >specific rooting point in the DNS hierarchy), and perhaps writing a second >e164.arpa implementation profile document? Scott, Thank you for making this point. It's scaling properties are quite interesting. Being clear about policy versus protocol is important. Deciding what, exactly, is really amenable to separation is sometimes a challenge. That's why I believe that email should specify a protocol with semantics about the originator, but giving users the freedom to implement different policies for choosing the name of the originator field. After all, people use different languages, so you and I might like From but the French and Spanish might prefer De, and the Malaysians are like to want Dari. At 04:28 PM 2/22/2002 -0500, Tony Rutkowski wrote: >Hi Patrik, >You might look at the RBL services arena - which is >very much DNS based, Hi, Tony. This is easily your most creative entropy-inducing effort to date. Either that, or it is your most non-sequitorish effort to date. >Providers and customers do work these things out in >the marketplace without the need for governmental >intervention to bless somebody's best-loved namespace. Perhaps this explains the difficulties you have with IETF process. You seem unaware that it is a voluntary collaborative effort, with no enforcement powers. The fact that it produces specifications that make constrained, direct decisions -- rather than leaving everything open for future negotiation -- does not change the community basis of its adoption and use. (Offhand, the EDI standards world is probably best suited to the model you appear to be espousing.) Perhaps you have not noticed that one of that actual benefits of the IETF work is that it does not do the kind of technical equivocation you seek. No doubt your early training in other standards venues made it difficult to appreciate this point of distinction. After all, five different connection-oriented transport protocols clearly would have been superior to the IETF's constraint to only one. And hence, dear Tony, you need to take your political concerns to places that match the criteria you object to. The IETF is not one of them. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 23 02:11:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16899 for ; Sat, 23 Feb 2002 02:11:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01270 for enum-archive@odin.ietf.org; Sat, 23 Feb 2002 02:11:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00988; Sat, 23 Feb 2002 02:03:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00957 for ; Sat, 23 Feb 2002 02:03:16 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13231 for ; Sat, 23 Feb 2002 02:03:14 -0500 (EST) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id XAA27794; Fri, 22 Feb 2002 23:02:56 -0800 Message-Id: <5.1.0.14.2.20020222225746.031e6aa0@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Feb 2002 22:58:49 -0800 To: Kevin McCandless From: Dave Crocker Subject: RE: [Enum] ENUM individual draft on root domain. Cc: "'mark.harris@enumforums.org'" , Eric Brunner-Williams in Portland Maine , enum@ietf.org In-Reply-To: <1C1EEC765F843E44996971A80682118B014B101C@opwinex01.corp.il luminet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org It's good that you like simplicitly. In that spirit: At 11:05 AM 2/22/2002 -0800, Kevin McCandless wrote: >1) ENUM is not .arpa and to say so is allowing policy to be set in an IETF >draft. ENUM can reside in any TLD. please point to the approved standards specification that permits this flexibility. d/ ps. for extra credit, please resolve the contradiction that that specification creates with respect to the relevant IETF standards document. ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 23 03:11:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17460 for ; Sat, 23 Feb 2002 03:11:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA03372 for enum-archive@odin.ietf.org; Sat, 23 Feb 2002 03:11:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02966; Sat, 23 Feb 2002 03:01:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02843 for ; Sat, 23 Feb 2002 03:01:04 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17345 for ; Sat, 23 Feb 2002 03:01:01 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA03750; Sat, 23 Feb 2002 09:00:26 +0100 (MET) Date: Sat, 23 Feb 2002 08:40:03 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Hollenbeck, Scott" , enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Message-ID: <13579809.1014453603@localhost> In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B6FE@vsvapostal3.bkup6> References: <3CD14E451751BD42BA48AAA50B07BAD60189B6FE@vsvapostal3.bkup6> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-22 14.13 -0500 "Hollenbeck, Scott" wrote: > A different suggestion given the above: please be very clear in 2916bis > that the document describes a system, and not just a protocol > specification. Given the first sentence in the "Status of this Memo" > boilerplate from the current 2916 [1], I think it would be wise to > explicitly note that there is more than an implementation-neutral > protocol described in the document. Perhaps a sentence like this at the > beginning of the first paragraph in the introduction: > > "This document includes a protocol specification and specific > implementation requirements that define the ENUM system." Michael privately to me suggested the following change based on input from you, and I liked the change. This was sent from him to me in the very last second before the draft had to be submitted before the cutoff. I don't think the change made it, but in that case we will change text in 1.2 after the IETF meeting. Please think about what (kind) of change make you happy. The one below is a suggestion from Michael. > Section 1.2 currently reads: > > This document specifies how "ENUM" works, that is how to handle numbers > allocated according to the ITU-T standard E.164. But, a similar mechanism > can be used also for other numbers, such as private dialing plans. > Suggested change is that (a) a different domain, well-known for all > parties using the same dialing plan, is selected and (b) the application > unique string (see section 3.1 below) is to be the full number > as specified but without the leading '+'. > > How 'bout this: > > This document specifies the "ENUM System", that is, procedures and > infrastructure that provide a service that can convert numbers allocated > according to the ITU-T standard E.164 into Uniform Resource Identifiers. > But, the mechanisms described here can be used for other numbers or > purposes such as private dialing plans, enterprise level private > services, etc. If this is being done then the two suggested methods of > differentiating the private space are a) a different domain, well-known > for all parties using the same private system and b) the Application > Unique String is used, minus the leading "+". These two options are all > that's necessary to differentiate the ENUM system from private > implementations of the same techniques. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 23 08:03:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19416 for ; Sat, 23 Feb 2002 08:03:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA12315 for enum-archive@odin.ietf.org; Sat, 23 Feb 2002 08:03:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11723; Sat, 23 Feb 2002 07:54:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11693 for ; Sat, 23 Feb 2002 07:54:19 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19337 for ; Sat, 23 Feb 2002 07:54:16 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA12315; Sat, 23 Feb 2002 07:52:50 -0500 (EST) Received: from fractal.verisign.com (10.145.9.138 [10.145.9.138]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15YH4ZVT; Sat, 23 Feb 2002 07:52:49 -0500 Message-Id: <5.1.0.14.2.20020223072225.01ba0b68@216.168.234.202> X-Sender: trutkowski@216.168.234.202 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Feb 2002 07:52:44 -0500 To: Jim Reid From: Tony Rutkowski Subject: Re: [Enum] ENUM individual draft on root domain. Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , mark.harris@enumforums.org, Richard Shockey , "Hollenbeck, Scott" , enum@ietf.org In-Reply-To: <45667.1014435973@shell.nominum.com> References: <5.1.0.14.2.20020222161314.0279b130@vsvapostal1.prod.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Jim, >them. If applications chooose not to perform ENUM lookups, they can't >make use of ENUM based services. Not even in your parallel universes. Actually, so is ENUM. The "authoritative" E164 resource records are the property of telecom carriers and resident as IN Network Elements. That's unlikely to change. The IAB's proposed e164.arpa is just one provider's private parallel universe to potential ancillary services. NetNumber has another one. ICQ another. So does Stupi AB. >Please tell us where customers and providers have created a market in >reverse lookup name spaces for IPv4 or IPv6 addresses. With our >without government intervention. Of course, it would be trivially simple, and indeed, some private ones exist. However, the present free service provided by existing players doesn't incent such a market emerging. RBL remains a good model for how a new, large-scale DNS based and ENUM-like pointer service can emerge that provides customer choice among multiple providers and differing business models. Hope this provides some food for thought even if you don't like the idea. cheers, --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Feb 23 10:09:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20703 for ; Sat, 23 Feb 2002 10:09:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17193 for enum-archive@odin.ietf.org; Sat, 23 Feb 2002 10:09:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16402; Sat, 23 Feb 2002 09:59:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16373 for ; Sat, 23 Feb 2002 09:59:41 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20539 for ; Sat, 23 Feb 2002 09:59:38 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA13326; Sat, 23 Feb 2002 09:58:58 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <15YH45WS>; Sat, 23 Feb 2002 09:58:58 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B707@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , enum@ietf.org Subject: RE: [Enum] ENUM individual draft on root domain. Date: Sat, 23 Feb 2002 09:58:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA16374 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Patrik F�ltstr�m [mailto:paf@cisco.com] > Sent: Saturday, February 23, 2002 2:40 AM > To: Hollenbeck, Scott; enum@ietf.org > Subject: RE: [Enum] ENUM individual draft on root domain. > > > Michael privately to me suggested the following change based > on input from > you, and I liked the change. This was sent from him to me in > the very last > second before the draft had to be submitted before the cutoff. I don't > think the change made it, but in that case we will change > text in 1.2 after > the IETF meeting. > > Please think about what (kind) of change make you happy. The > one below is a > suggestion from Michael.. [snip] Michael and I exchange some off-list mail on the same text. The change suggested makes the point that I think needed to be reinforced; I'm OK with it. -Scott- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 24 12:46:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14015 for ; Sun, 24 Feb 2002 12:46:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20322 for enum-archive@odin.ietf.org; Sun, 24 Feb 2002 12:46:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19807; Sun, 24 Feb 2002 12:36:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19776 for ; Sun, 24 Feb 2002 12:36:49 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13879 for ; Sun, 24 Feb 2002 12:36:44 -0500 (EST) Received: from [10.0.1.12] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 1A7503190C; Sun, 24 Feb 2002 09:36:47 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Sun, 24 Feb 2002 09:36:49 -0800 Subject: Re: [Enum] ENUM individual draft on root domain. From: David Conrad To: Dave Crocker , Kevin McCandless Cc: "'mark.harris@enumforums.org'" , Eric Brunner-Williams in Portland Maine , enum wg Message-ID: In-Reply-To: <5.1.0.14.2.20020222225746.031e6aa0@127.0.0.1> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Dave, On 2/22/02 10:58 PM, "Dave Crocker" wrote: > At 11:05 AM 2/22/2002 -0800, Kevin McCandless wrote: >> 1) ENUM is not .arpa and to say so is allowing policy to be set in an IETF >> draft. ENUM can reside in any TLD. > please point to the approved standards specification that permits this > flexibility. See RFC 1034/1035. The DNS doesn't care about the magic string that is appended onto the end of the reversed set of digits that make up the domain name looked up per ENUM. ENUM can work just as well if my telephone number gets translated into 3.0.0.6.1.8.3.0.5.6.1.fun.brandenburg.com as it would as 3.0.0.6.1.8.3.0.5.6.1.e164.arpa. It would be really nice, however, if we could all agree on the _single_ string to append. Unfortunately, this is appearing increasingly unlikely. Rgds, -drc _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 24 13:11:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14376 for ; Sun, 24 Feb 2002 13:11:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21644 for enum-archive@odin.ietf.org; Sun, 24 Feb 2002 13:11:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21233; Sun, 24 Feb 2002 13:02:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21205 for ; Sun, 24 Feb 2002 13:02:22 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14246 for ; Sun, 24 Feb 2002 13:02:19 -0500 (EST) Received: from [10.0.1.12] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 919A731926; Sun, 24 Feb 2002 10:02:19 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Sun, 24 Feb 2002 10:01:32 -0800 Subject: Re: [Enum] ENUM individual draft on root domain. From: David Conrad To: Tony Rutkowski , Jim Reid Cc: Patrik F=?ISO-8859-1?B?5Gx0c3Ry9g==?=m , , Richard Shockey , "Hollenbeck, Scott" , enum wg Message-ID: In-Reply-To: <5.1.0.14.2.20020223072225.01ba0b68@216.168.234.202> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Tony, On 2/23/02 4:52 AM, "Tony Rutkowski" wrote: >> Please tell us where customers and providers have created a market in >> reverse lookup name spaces for IPv4 or IPv6 addresses. > Of course, it would be trivially simple, and indeed, some > private ones exist. Trivially simple? Given in-addr.arpa and ip6.arpa are a part of every resolver library included in every DNS lookup supporting programming language library, both embedded and not since 1985, trying to migrate to an alternative to these domains would be _FAR_ from trivial. What might be trivial would be to spoof the global in-addr/ip6.arpa to a local version (which, of course, won't work with DNSSEC, but we'll ignore that). Pointers to the "private ones" you mention would be interesting. > RBL remains a good model for how a new, large-scale DNS > based and ENUM-like pointer service can emerge that provides > customer choice among multiple providers and differing > business models. The reason multiple RBLs exist is that it is trivial for _anyone_ to get the authoritative data in real-time as to whether a mail server should be on the RBL (can mail be relayed? Yes: rbl 'em). How would one go about getting real-time access to the (globally distributed) telephone number database, particularly given that I suspect some owners of parts of that database would be singularly uninterested in opening up access to arrogant American startup companies? Rgds, -drc _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 24 13:11:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14392 for ; Sun, 24 Feb 2002 13:11:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21658 for enum-archive@odin.ietf.org; Sun, 24 Feb 2002 13:11:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21276; Sun, 24 Feb 2002 13:02:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21240 for ; Sun, 24 Feb 2002 13:02:28 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14249 for ; Sun, 24 Feb 2002 13:02:25 -0500 (EST) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA20304; Sun, 24 Feb 2002 10:01:53 -0800 Message-Id: <5.1.0.14.2.20020224094839.03671af8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 24 Feb 2002 10:01:41 -0800 To: David Conrad From: Dave Crocker Subject: Re: [Enum] ENUM individual draft on root domain. Cc: Kevin McCandless , "'mark.harris@enumforums.org'" , Eric Brunner-Williams in Portland Maine , enum wg In-Reply-To: References: <5.1.0.14.2.20020222225746.031e6aa0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org David, Your note highlights confusion between DNS technology and ENUM service. An assertion was made about ENUM, not about the DNS. I asked for documentation to support that assertion. You responded with two large, generic citations about the underlying DNS. Since no one was talking about the broad range of DNS capabilities, I cannot even guess why you thought those citations are relevant. Once again: Where does it say that ENUM is not e164.arpa? The term came from this working group. Note that the ITU, for example, is very clear about this, e.g., . The USG similarly constrains itself to that perspective in except for a broad hypothetical in an appendix. So anyone claiming that ENUM is other than, or more than, e164.arpa, needs to provide documentation of standards work that substantiates this. Otherwise, the assertion of broader meaning is a matter of personal preference, rather than institutional agreement. d/ At 09:36 AM 2/24/2002 -0800, David Conrad wrote: >Dave, > >On 2/22/02 10:58 PM, "Dave Crocker" wrote: > > At 11:05 AM 2/22/2002 -0800, Kevin McCandless wrote: > >> 1) ENUM is not .arpa and to say so is allowing policy to be set in an > IETF > >> draft. ENUM can reside in any TLD. > > please point to the approved standards specification that permits this > > flexibility. > >See RFC 1034/1035. The DNS doesn't care about the magic string that is >appended onto the end of the reversed set of digits that make up the domain >name looked up per ENUM. ENUM can work just as well if my telephone number >gets translated into 3.0.0.6.1.8.3.0.5.6.1.fun.brandenburg.com as it would >as 3.0.0.6.1.8.3.0.5.6.1.e164.arpa. > >It would be really nice, however, if we could all agree on the _single_ >string to append. Unfortunately, this is appearing increasingly unlikely. > >Rgds, >-drc > ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 24 15:02:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15523 for ; Sun, 24 Feb 2002 15:02:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25503 for enum-archive@odin.ietf.org; Sun, 24 Feb 2002 15:02:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24862; Sun, 24 Feb 2002 14:53:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24832 for ; Sun, 24 Feb 2002 14:53:08 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15350 for ; Sun, 24 Feb 2002 14:53:02 -0500 (EST) Received: from [10.0.1.12] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 86EAD31926; Sun, 24 Feb 2002 11:52:56 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Sun, 24 Feb 2002 11:51:39 -0800 Subject: Re: [Enum] ENUM individual draft on root domain. From: David Conrad To: Dave Crocker Cc: Kevin McCandless , "'mark.harris@enumforums.org'" , Eric Brunner-Williams in Portland Maine , enum wg Message-ID: In-Reply-To: <5.1.0.14.2.20020224094839.03671af8@127.0.0.1> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Just to be clear: You appear to be arguing that if there is an implementation of mapping E164 identifiers into the domain name system that follows 2916 letter for letter, in particular, demanding a single DNS tree, but uses (say) .e164.itu.int, instead of .e164.arpa, that this would not be "ENUM". Seems a bit pedantic to me. As I'm more interested in trying to get the functionality described in 2916 implemented than in political posturing, I don't actually care what the domain name string appended is as long as the technology described is operationally deployable and usable. Pragmatically speaking, it remains to be seen (at least to me) whether the community of interests that define the stuff we're trying to map into the DNS will go along with e164.arpa. Rgds, -drc On 2/24/02 10:01 AM, "Dave Crocker" wrote: > David, > > Your note highlights confusion between DNS technology and ENUM service. > > An assertion was made about ENUM, not about the DNS. I asked for > documentation to support that assertion. > > You responded with two large, generic citations about the underlying > DNS. Since no one was talking about the broad range of DNS capabilities, I > cannot even guess why you thought those citations are relevant. > > Once again: Where does it say that ENUM is not e164.arpa? > > The term came from this working group. > > Note that the ITU, for example, is very clear about this, e.g., > . > > The USG similarly constrains itself to that perspective in > al.doc> > except for a broad hypothetical in an appendix. > So anyone claiming that ENUM is other than, or more than, e164.arpa, needs > to provide documentation of standards work that substantiates this. > > Otherwise, the assertion of broader meaning is a matter of personal > preference, rather than institutional agreement. > > d/ > > At 09:36 AM 2/24/2002 -0800, David Conrad wrote: >> Dave, >> >> On 2/22/02 10:58 PM, "Dave Crocker" wrote: >>> At 11:05 AM 2/22/2002 -0800, Kevin McCandless wrote: >>>> 1) ENUM is not .arpa and to say so is allowing policy to be set in an >> IETF >>>> draft. ENUM can reside in any TLD. >>> please point to the approved standards specification that permits this >>> flexibility. >> >> See RFC 1034/1035. The DNS doesn't care about the magic string that is >> appended onto the end of the reversed set of digits that make up the domain >> name looked up per ENUM. ENUM can work just as well if my telephone number >> gets translated into 3.0.0.6.1.8.3.0.5.6.1.fun.brandenburg.com as it would >> as 3.0.0.6.1.8.3.0.5.6.1.e164.arpa. >> >> It would be really nice, however, if we could all agree on the _single_ >> string to append. Unfortunately, this is appearing increasingly unlikely. >> >> Rgds, >> -drc >> > > ---------- > Dave Crocker > Brandenburg InternetWorking > tel +1.408.246.8253; fax +1.408.273.6464 > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 24 15:40:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15888 for ; Sun, 24 Feb 2002 15:40:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26696 for enum-archive@odin.ietf.org; Sun, 24 Feb 2002 15:40:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26444; Sun, 24 Feb 2002 15:31:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26416 for ; Sun, 24 Feb 2002 15:31:48 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15775 for ; Sun, 24 Feb 2002 15:31:43 -0500 (EST) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA25199; Sun, 24 Feb 2002 12:31:42 -0800 Message-Id: <5.1.0.14.2.20020224122735.03671160@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 24 Feb 2002 12:30:46 -0800 To: David Conrad From: Dave Crocker Subject: Re: [Enum] ENUM individual draft on root domain. Cc: enum wg In-Reply-To: References: <5.1.0.14.2.20020224094839.03671af8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:51 AM 2/24/2002 -0800, David Conrad wrote: >Just to be clear: > >You appear to be arguing that if there is an implementation of mapping E164 >identifiers into the domain name system that follows 2916 letter for letter, >in particular, demanding a single DNS tree, but uses (say) .e164.itu.int, >instead of .e164.arpa, that this would not be "ENUM". if there were a transport protocol that used TCP, except for making the port number field larger and using fixed-interval retransmission rates, would that still be TCP? If you used RFC 2822, except renamed all the headers to some other set of strings and you changed the format of an address, would that still be Internet standard mail? These are, of course, rhetorical questions. >Seems a bit pedantic to me. Ahh. Glad to see you are appreciating the nature of standards. By there essence, they are supposed to be pedantic. Otherwise, they are certain to have no interoperability. Interoperability? You know, the sort of thing one loses if you have independent naming trees, anchored in different places of the DNS... d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 24 19:27:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17546 for ; Sun, 24 Feb 2002 19:27:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA04545 for enum-archive@odin.ietf.org; Sun, 24 Feb 2002 19:27:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04318; Sun, 24 Feb 2002 19:18:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04292 for ; Sun, 24 Feb 2002 19:18:22 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17488 for ; Sun, 24 Feb 2002 19:18:20 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id TAA29718; Sun, 24 Feb 2002 19:16:41 -0500 (EST) Received: from fractal.verisign.com (10.145.9.139 [10.145.9.139]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 15YHVNB0; Sun, 24 Feb 2002 19:16:41 -0500 Message-Id: <5.1.0.14.2.20020224182525.00bbb010@216.168.234.202> X-Sender: trutkowski@216.168.234.202 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 24 Feb 2002 19:16:34 -0500 To: David Conrad , Jim Reid From: Tony Rutkowski Subject: Re: [Enum] ENUM individual draft on root domain. Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , , Richard Shockey , "Hollenbeck, Scott" , enum wg In-Reply-To: References: <5.1.0.14.2.20020223072225.01ba0b68@216.168.234.202> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 01:01 PM 2/24/2002, David Conrad wrote: >How would one go about getting real-time access to the (globally >distributed) telephone number database, particularly given that I suspect >some owners of parts of that database would be singularly uninterested in >opening up access to arrogant American startup companies? Hi David, Agreed - many implementations are technically trivial, but the economics and constraints of the embedded base make it otherwise. Like it or not, the only "authoritative" E.164 database is SS7 based, and increasingly represented as Network Elements within the Intelligent Network. For many reasons - technical, commercial, legal, national security - this is unlikely to change anytime soon. Bundling the ENUM protocol *and* the administrative schema together is almost certain to result in failure, since even the authoritative E.164 world itself is based on diverse autonomous national schema where the "resource records" are often never shared even with a closed club of providers. Even within the U.S., the information is shared only among members of the club - i.e., telecom providers - and only because of regulatory mandates. The European Commission is considering similar limited liberalization. In an environment where 2/3 of the countries of the world ban IP telephony, it's not likely that they're going to populate authoritative resource records in a common DNS zone for others to use. A certain pragmatism is going to be required here that reflects the diversity of the real world. It's going to include multiple diverse DNS zones where a few are maintained (probably in DNS VPNs) by national regulatory fiat, where some are ported in part as UNEs from the IN databases, where some are specially allocated E164 blocks, and where some are non-authoritatively but reliably supplemented by entrepreneurs. Any authoritative implementation is also going to be fraught with significant diverse obstacles that include mandatory requirements like Local Number Portability, E911, competitive directory assistance, UNEs, Caller ID, unwanted solicitation control, and LI/CALEA. There are no simple answers here. But one thing seems certain - a monolithic ENUM approach where protocol and administration are bundled together is dead-on- arrival. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Feb 24 21:36:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19953 for ; Sun, 24 Feb 2002 21:36:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA10108 for enum-archive@odin.ietf.org; Sun, 24 Feb 2002 21:36:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09189; Sun, 24 Feb 2002 21:27:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09158 for ; Sun, 24 Feb 2002 21:27:23 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18839 for ; Sun, 24 Feb 2002 21:27:19 -0500 (EST) Received: from [10.0.1.13] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 8250B3190C; Sun, 24 Feb 2002 18:27:20 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Sun, 24 Feb 2002 18:27:24 -0800 Subject: Re: [Enum] ENUM individual draft on root domain. From: David Conrad To: Dave Crocker Cc: enum wg Message-ID: In-Reply-To: <5.1.0.14.2.20020224122735.03671160@127.0.0.1> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Dave, On 2/24/02 12:30 PM, "Dave Crocker" wrote: > Interoperability? > > You know, the sort of thing one loses if you have independent naming trees, > anchored in different places of the DNS... You seem to be missing the bit where I said "a single tree". If the IESG/IAB can convince all the administrators of the numbering plans to play along with e164.arpa, then life is simple. Unfortunately, I'm skeptical that life will be that simple... Rgds, -drc _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Feb 25 01:04:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22960 for ; Mon, 25 Feb 2002 01:04:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA18608 for enum-archive@odin.ietf.org; Mon, 25 Feb 2002 01:04:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17862; Mon, 25 Feb 2002 00:54:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17828 for ; Mon, 25 Feb 2002 00:54:32 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22840 for ; Mon, 25 Feb 2002 00:54:30 -0500 (EST) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id VAA10473; Sun, 24 Feb 2002 21:54:31 -0800 Message-Id: <5.1.0.14.2.20020224215015.01fb5090@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 24 Feb 2002 21:54:18 -0800 To: David Conrad From: Dave Crocker Subject: Re: [Enum] ENUM individual draft on root domain. Cc: enum wg In-Reply-To: References: <5.1.0.14.2.20020224122735.03671160@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 06:27 PM 2/24/2002 -0800, David Conrad wrote: > > You know, the sort of thing one loses if you have independent naming trees, > > anchored in different places of the DNS... > >You seem to be missing the bit where I said "a single tree". If the >IESG/IAB can convince all the administrators of the numbering plans to play >along with e164.arpa, then life is simple. Unfortunately, I'm skeptical >that life will be that simple... This began as a question about the use of the term Enum. You have cleverly turned it into a question about multiple trees. Here are some facts: Enum is a term that specifies the work of the Enum working group. That work produced a specification That specification calls for a particular naming tree, anchored in e164.arpa. 1. If any of the above facts is incorrect, please document the alternative truth you are asserting. 2. As with all other activities in an open world, people and networks are free to adopt this specification or another, as they wish. What they are NOT free to do, with any honesty or integrity, is to adopt something else but claim they haven't. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Feb 25 02:12:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01407 for ; Mon, 25 Feb 2002 02:12:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA00727 for enum-archive@odin.ietf.org; Mon, 25 Feb 2002 02:12:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00461; Mon, 25 Feb 2002 02:03:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00430 for ; Mon, 25 Feb 2002 02:03:07 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27582 for ; Mon, 25 Feb 2002 02:03:04 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA02765 for ; Mon, 25 Feb 2002 08:02:35 +0100 (MET) Date: Mon, 25 Feb 2002 07:52:40 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum wg Subject: Re: [Enum] ENUM individual draft on root domain. Message-ID: <18744710.1014623560@localhost> In-Reply-To: <5.1.0.14.2.20020224215015.01fb5090@127.0.0.1> References: <5.1.0.14.2.20020224122735.03671160@127.0.0.1> <5.1.0.14.2.20020224215015.01fb5090@127.0.0.1> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Have the people discussing this subject (whatever it is) read 2916bis? Part from Dave Crocker which is very close to the current wording, so I suspect he cheated ;-) I have still to see any constructive comments on proposed changes in 2916bis which makes you more happy. Given suggestions, we can see if we have consensus in the wg to make them. Without suggestions, I only see massive amounts of hot air. paf --On 2002-02-24 21.54 -0800 Dave Crocker wrote: > At 06:27 PM 2/24/2002 -0800, David Conrad wrote: >> > You know, the sort of thing one loses if you have independent naming >> > trees, anchored in different places of the DNS... >> >> You seem to be missing the bit where I said "a single tree". If the >> IESG/IAB can convince all the administrators of the numbering plans to >> play along with e164.arpa, then life is simple. Unfortunately, I'm >> skeptical that life will be that simple... > > > This began as a question about the use of the term Enum. You have > cleverly turned it into a question about multiple trees. > > Here are some facts: > > > Enum is a term that specifies the work of the Enum working group. > > That work produced a specification > > That specification calls for a particular naming tree, anchored > in e164.arpa. > > 1. If any of the above facts is incorrect, please document the > alternative truth you are asserting. > > 2. As with all other activities in an open world, people and networks > are free to adopt this specification or another, as they wish. > > What they are NOT free to do, with any honesty or integrity, is to adopt > something else but claim they haven't. > > d/ > > > ---------- > Dave Crocker > Brandenburg InternetWorking > tel +1.408.246.8253; fax +1.408.273.6464 > > > _______________________________________________ > 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 daemon@optimus.ietf.org Mon Feb 25 10:58:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15057 for ; Mon, 25 Feb 2002 10:58:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28076 for enum-archive@odin.ietf.org; Mon, 25 Feb 2002 10:58:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27633; Mon, 25 Feb 2002 10:49:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27604 for ; Mon, 25 Feb 2002 10:49:16 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14580 for ; Mon, 25 Feb 2002 10:49:12 -0500 (EST) Received: from [10.0.1.14] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E1FC93190D; Mon, 25 Feb 2002 07:49:14 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Mon, 25 Feb 2002 07:49:19 -0800 Subject: Re: [Enum] ENUM individual draft on root domain. From: David Conrad To: Dave Crocker Cc: enum wg Message-ID: In-Reply-To: <5.1.0.14.2.20020224215015.01fb5090@127.0.0.1> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Dave, On 2/24/02 9:54 PM, "Dave Crocker" wrote: > This began as a question about the use of the term Enum. You have cleverly > turned it into a question about multiple trees. Saturation level reached. I have NEVER spoken about multiple trees in this thread. Not sure what conversation you're involved in, but as I'm not a part of it, this will be my last comment on this thread. Rgds, -drc _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Feb 25 12:04:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18906 for ; Mon, 25 Feb 2002 12:04:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA04171 for enum-archive@odin.ietf.org; Mon, 25 Feb 2002 12:04:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02341; Mon, 25 Feb 2002 11:55:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02230 for ; Mon, 25 Feb 2002 11:55:17 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18238 for ; Mon, 25 Feb 2002 11:55:12 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA29406; Mon, 25 Feb 2002 17:54:43 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA28118; Mon, 25 Feb 2002 17:54:36 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id <1DHMWN0M>; Mon, 25 Feb 2002 17:54:45 +0100 Message-ID: From: Brandner Rudolf To: enum wg Cc: "'paf@cisco.com'" , "'rich.shockey@neustar.biz'" , Conroy Lawrence Date: Mon, 25 Feb 2002 17:54:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] FYI: draft-brandner-enum-tel-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi all, sorry if I am disturbing you, but to give you some relief (or maybe not) of the recent mailing list traffic, I have appended a draft, which we submitted on Friday (yes, before cut off) for the ENUM WG with a suggested name draft-brandner-enum-tel-00.txt. As I suspect, it will take some time until it surfaces on the announce list, so here it is. Comments are always welcome, constuctive ones especially. .... and now back to what went was going on .... Have a nice day, Rudi ------------------------------------------------------------------------- ENUM Working Group R.Brandner Internet-Draft Siemens L. Conroy Siemens Expires: September 22, 2002 February 22, 2002 "The ENUM 'tel' enumservice" draft-brandner-enum-tel-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 22, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes the enumservice 'tel' and how it is used with an ENUM application when indicated within a returned a NAPTR record. It gives guidelines for the treatment of records having this sub-field value, and for the onward processing of information gleaned from the enclosing NAPTR record. Brandner & Conroy Expires August 22, 2002 [Page 1] Internet-Draft The ENUM 'tel' enumservice February 2002 1. 'tel' enumservice registration template As defined in [1], the following is a template covering information needed for the registration of the enumservice specified in this document. Service Name: "tel" URI Scheme(s): "tel:" Functional Specification: see section 3 of this document Security considerations: see section 5 of this document Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) COMMON Author: Rudolf Brandner Any other information that the author deems interesting: see sections 2 and 4 of this document 2. Introduction The ENUM application is defined in [1]. This takes an input E.164 number and returns a URI (or set of URIs) by which communications services associated with that E.164 number[2] can be contacted. This process is called a "resolution service" provided by the client application. The data for this information is stored within the DNS[3][4], inside NAPTR resource records (defined in [5], section 4). The ENUM application specification defines the structure for one of the fields of the NAPTR records it will use; the "Services" field. ENUM expects this field to be structured in two parts, the rs (or resolution service) tag and the enumservice sub-field. This latter can in turn have multiple values, each of which is preceded by a '+' character. The "resolution service" for which a NAPTR record is intended for use is indicated by the record rs sub-field value. In the case of records intended for use with ENUM, this tag value will be "E2U" (meaning that the record is designed for use when taking an E.164 number and results in a URI). Brandner & Conroy Expires August 22, 2002 [Page 2] Internet-Draft The ENUM 'tel' enumservice February 2002 In addition to this tag, each NAPTR record for use by ENUM will include at least one enumservice identifier. Each of the values in this sub-field indicates a treatment that should be made of the returned URI, together with the IP-based protocol that should be used to forward the URI to an entity that can further a request for communication. This document describes one such treatment, that indicated by the 'tel' enumservice sub-field value. 2.1. ENUM enumservice sub-field ENUM is designed to retrieve URIs associated with an E.164 number. Note that each URI will be associated with its own set of enumservice sub-field values. Each value specifies two features; the treatment of the URI and the protocol to be used for onward processing. It is necessary to indicate the intended treatment and protocol to be used, as some user agents are capable of dealing with a number of different URI scheme values, so that the scheme alone cannot necessarily be used to distinguish what should be done with the URI; the URI is merely an identifier. For example, a URI with the scheme "mailto:" [6] implies that an email service can be used to contact the destination. However, it is unclear whether or not that user should be contacted using "basic" SMTP [7], or instead requires a secure connection to be made (using TLS, over which the SMTP protocol is carried, according to [8]). This might be indicated by a distinct enumservice sub-field value (say "smtp" or "smtps"), indicating the intended treatment and protocol to be used for the URI. In principle, these are NOT the same; the treatment is distinct from the protocol used to forward the URI to an entity that can further the communications processing, and, as just suggested, these may both differ from the URI scheme. However, for current uses, a single enumservice sub-field value, in conjunction with the URI scheme, will suffice. 3. 'tel' sub-field definition When used with an ENUM application, a NAPTR record including the indicator 'tel' in the enumservice sub-field implies that the URI can be treated as formatted according to [9], and includes a telephone number. This implies that the communications service described by this record will require a telephone connection to be made. Brandner & Conroy Expires August 22, 2002 [Page 3] Internet-Draft The ENUM 'tel' enumservice February 2002 This sub-field value differs from others that can be used with ENUM in that it does not specify the protocol to be used for onward processing, only the treatment of the URI with which it is associated. For example, it is a valid response to apply the associated URI to a remote SIP User Agent (and so to use SIP as the protocol by which the communication session is initiated). That external user agent would use this "tel:" URI to initiate a call (via a PSTN/IP Gateway as required). When a 'tel' enumservice sub-field value is present, the interpretation of the URI that results from processing with the enclosing NAPTR record is that it is a telephone number. This means that the URI MUST have a scheme of "tel:", or the client will treat the NAPTR as being in error. In such an error situation, the client SHOULD report this error and MUST NOT attempt to infer the treatment from the URI scheme. The client MAY use the email contact address held in the SOA record for the current DNS zone to report the mis-configuration of the NAPTR. By implication, there SHOULD be a SOA record with a valid email contact address available within the DNS zone holding NAPTR records. 4. Recommendations on the use of 'tel' NAPTR records The 'tel: URL scheme (RFC2806 [8]) allows considerable flexibility. Where a URI is to hold a telephone number and is to be used by ENUM, however, there are some issues that should be considered. These are recommendations on the information to be encoded into NAPTR records that hold the 'tel' enumservice sub-field. If these recommendations are not followed, the results when such NAPTRs are processed by an ENUM client may not be acceptable. 4.1. Locality of caller ENUM is designed to allow information to be returned to clients regardless of their location. Thus, although RFC2806 allows for both "internationally significant" global-phone-subscriber or local-phone-subscriber formats for telephone numbers, the person authoritative for the content of a NAPTR record has no way of knowing the locality of the person who subsequently will request information associated with this data. It is therefore important that only the global-phone-subscriber form SHOULD be used. In those cases where a local-phone-subscriber form cannot be avoided, then there MUST be a global-area-specifier parameter included within the URI. This differs from RFC2806, in which this is of SHOULD strength. Brandner & Conroy Expires August 22, 2002 [Page 4] Internet-Draft The ENUM 'tel' enumservice February 2002 Thus these are acceptable forms: -- global phone subscriber form -- local phone subscriber form whilst the following is not acceptable: 4.2. Use of Telephone Service Provider parameter It is recommended that, where a NAPTR output is to be treated according to this document, the Telephone Service Provider (TSP) parameter SHOULD be included within the tel: URI. This parameter indicates the telephone service provider that is associated with the telephone number. This parameter is specified as including a value that is a fully qualified domain name. There are several reasons for doing this. It allows a "hint" at the organization responsible for providing telephone service to that destination user. This information might be used by the caller, for example, to select an appropriate PSTN/IP Gateway, if needed and the caller has no preference. Note that this service provider information is distinct from the identity of the administrative or technical contacts for the zone or its parent. This parameter may also be useful if, for example, there is a problem with calling that user, or there is reason to believe that problem calls are made from a phone number that (when passed to ENUM) has returned this URI. In these last two cases, the tsp domain name could either be used by the calling user to guess at the web server for that provider, or instead the web site could be found by submitting the domain name to DNS (using a SRV query). Having found this, the web site could be used to get contact information for that provider. As an alternative use of the tsp parameter domain name value, the DNS zone indicated by this tsp domain might have communications contact information (using an application similar to ENUM, but operating with records not in the ".e164.arpa." domain). As an aside, it would also be possible to include another NAPTR record inside that domain with a tel: URI holding the "prefix dial string" for use with this provider. Again, these would be returned by a query NOT in the "e164.arpa" domain space, and so would not use the ENUM application. Brandner & Conroy Expires August 22, 2002 [Page 5] Internet-Draft The ENUM 'tel' enumservice February 2002 4.3. Use of "tel:" URIs within ENUM for Redirection Teleservices Having received a tel: URI as the result of an ENUM query it is possible for a client node to re-submit the resulting telephone number (held inside the tel: URI) back into ENUM as a new query. This might be considered, for example, to deal with telephone service redirection. Configuring a set of tel: URIs in different zones, the contents of each of which "points" to others in the set, could be used to support a range of "follow-me" services. It is a very powerful feature, and reflects a number of "real-world" PSTN services. However, this feature does not come without risk. That risk is looping. 4.3.1. Looping of ENUM queries If re-submitting a tel: URI content to ENUM, mis-configuration of the NAPTR contents may cause a loop, in which the re-submission results in the same tel: URI, that is re-submitted, and so on. Likewise, a loop may exist with more than one domain involved. For example, an ENUM query with telephone number aa retrieves a NAPTR from domain A resulting in a tel: URI with telephone number bb; if this is resubmitted to ENUM, domain B (associated with this number) has a NAPTR that results in a tel: URI holding telephone number aa. If this is re-submitted, then the process repeats. This condition is an error, and the client that calls the ENUM application SHOULD report this to the end user and terminate the re-submission. The condition may have been caused by the remote administrator's mistake, but it is the client's problem; the ENUM application cannot detect the problem, as from its perspective each query returns correctly. For this reason, the client of an ENUM application should take extra care when re-submitting the telephone number contained in a tel: URI back into the ENUM application. It is exclusively the responsibility of the client of the ENUM application to keep track of prior queries and detect this condition. Any client behavior in the face of this problem is possible. However, it is recommended that: (i) the client does not re-submit a query to the ENUM application if it detects a loop. (ii) the client keeps track of the number of requests it has made in attempting to find information on an initial E.164 number; if this count exceeds a "reasonable maximum" value of 10 attempts, then it SHOULD treat the request chain as a loop. Brandner & Conroy Expires August 22, 2002 [Page 6] Internet-Draft The ENUM 'tel' enumservice February 2002 (iii) if it has good reason to do so, the client MAY treat the most recent distinct telephone number retrieved in the sequence as the one to be used to place a call. However, a loop condition IS an error, and so this behavior is not recommended. Instead, clients SHOULD be expected to abort the procedure that started the chain of requests and report the error to the end user, where possible. 4.3.2. Alternatives to tel: URI chains for Redirection Teleservices ENUM (and the tel enumservice), use DNS. As a result, all DNS facilities are available. This includes the use of CNAME resource records within a zone. It is possible to install a CNAME record in the parent of the zone associated with a particular E.164 number. If that CNAME points at another zone within the ".e164.arpa." domain, then the effect is to continue the DNS lookup chain at that point in the domain space. This is similar in effect; a redirection can be arranged by inserting a CNAME record into a parent zone. The effect is not quite the same as provision of a chain of "tel:" URIs. In the CNAME case, the process is transparent to the ENUM client; the lookup is merely continued at a different point in the DNS tree. It is less flexible, in that it precludes other records being stored within the zone associated with the donor number; the whole zone is bypassed. In contrast, a chain of tel: URIs still allows other records, and so allows a rich set of teleservices to be provisioned. Both configurations suffer from similar risks of looping, but in the case of CNAME loops these are either within the ENUM application or the DNS recursive resolver it uses. Despite its lack of flexibility, CNAME redirection can provide a simple method that may be appropriate for longer term fixed forwarding for administrators with the right to modify resource records within the parent of a zone associated with a number. Another issue with CNAME redirection is that it places some restrictions on the REGEXP content. At present, DDDS allows a regular expression to match against the AUS, and if there is no match then the record is discarded. Where a query is made on a zone associated with a phone number then NAPTR records within that zone could have RegExp fields that pattern matched against the whole number. Thus, if the number in its AUS format were "+441794833666", then a query on the zone "6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa." might return a NAPTR with a RegExp field of "!^(441794833666)$!\+\1!". This would match perfectly, and processing would continue. Brandner & Conroy Expires August 22, 2002 [Page 7] Internet-Draft The ENUM 'tel' enumservice February 2002 If, however, the query had been made starting with a phone number, in its AUS format, of "+494012345678", AND a CNAME record points from 8.7.6.5.4.3.2.1.0.4.9.4.e164.arpa. to 6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa., then the same NAPTR returned from the query would NOT match with the AUS. This means that administrators of ENUM zones should be careful about specifying the RegExp match rules too tightly. There are reasons to do this, however. For example, two NAPTR records might exist in the destination zone, with different priority. The record with the higher priority might match against an AUS holding any fully qualified phone number, whilst that with the lower priority might have a tight match against the phone number associated directly with that zone. The result would be that two different NAPTRs would match, depending on whether or not that phone number was the subject of the query, or instead the redirected, or donor, number. This would allow different treatment of requests, depending on which number was queried. This is not specific to 'tel' enumservice, but it does show the flexibility possible. 5. Security Considerations [Including but not limited to...] Any system that places calls should not automatically dial out to a number included in ENUM. The calling user should be given a chance to express policy. For example, a NAPTR output treated as a 'tel' value may result in a call being placed to a long distance, international, or premium rate number. Any dialer system that is passed the telephone number and uses it to dial out should be act carefully; accidental or malicious mis-configuration of a NAPTR record may result in calls being placed either to an innocent third party or to an otherwise inappropriate destination. Any system that places a call automatically (i.e. without the end user actually dialing the number themselves) runs the risk of those calls being incorrect. The end user should be involved in the call process, if only so that they can veto a call dialed to a "wrong" number or at the "wrong" time. This is particularly important if the ENUM infrastructure is ever used to allow "follow-me" service listing, possibly based on automatic "time of day" changes. [Ask any European whether or not they have received a call whilst in the US that was placed during European work hours] Brandner & Conroy Expires August 22, 2002 [Page 8] Internet-Draft The ENUM 'tel' enumservice February 2002 There might be an issue with Telephone Service Provider (TSP) privacy. If the ";tsp=" parameter (RFC 2806) is used in a tel: URI resulting from an ENUM query, an exhaustive lookup of ENUM will reveal data about how many ENUM users a TSP has. It is yet unclear how to distinguish between "normal" ENUM request behavior and an exhaustive lookup and how to prevent an exhaustive lookup. Particularly for a "niche" TSP providing services to a particular group, information on the user may be revealed by presence of the TSP field in a "tel:" URI. 6. IANA Considerations This document specifies the enumservice 'tel', i.e. the treatment of a URI within a NAPTR record that is intended for use by the ENUM application, when that NAPTR record includes the 'tel' enumservice sub-field value. To ensure that this sub-field value does not collide with other uses, it is necessary to register this NAPTR sub-field value, when used within ENUM. Thus this requests that this document be considered a specification for the sub-field value with the identifier 'tel', and that a registration be made for this within the ENUM enumservice name space, as specified in [1]. 7. Acknowledgements Brandner & Conroy Expires August 22, 2002 [Page 9] Internet-Draft The ENUM 'tel' enumservice February 2002 8. References [1] P. Faltstrom, "The E.164 to URI DDDS Application", draft-ietf-enum-rfc2916bis-01.txt, Work In Progress, March 2002 [2] ITU-T Recommendation E.164/I.331 (05/97): The International Public Telecommunication Numbering Plan. 1997. [3] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, STD 13, Nov 1987. [4] Mockapetris, P., "Domain names - concepts and facilities", RFC 1034, STD 13, Nov 1987. [5] M.Mealling, "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" draft-ietf-urn-dns-ddds-database-08.txt, Work In Progress, February 2002 [6] Hoffman, et. al., "The mailto URL scheme", RFC2368, July 1998 [7] Klensin, J., "Simple Mail Transfer Protocol", RFC821, August 1982 [8] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC2847, January 1999 [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC2806, April 2000 Brandner & Conroy Expires August 22, 2002 [Page 10] Internet-Draft The ENUM 'tel' enumservice February 2002 9. Authors' Addresses Rudolf Brandner Siemens ICN Hofmannstrasse 51 Munich Germany Email: rudolf.brandner@icn.siemens.de URI: http://www.siemens.de Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey U.K. email: lwc@roke.co.uk phone: Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Brandner & Conroy Expires August 22, 2002 [Page 11] _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Feb 25 12:22:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19648 for ; Mon, 25 Feb 2002 12:22:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05182 for enum-archive@odin.ietf.org; Mon, 25 Feb 2002 12:22:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04631; Mon, 25 Feb 2002 12:12:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04582 for ; Mon, 25 Feb 2002 12:12:43 -0500 (EST) Received: from t-6mnjnqs5jxuuc ([211.152.107.30]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19178 for ; Mon, 25 Feb 2002 12:12:38 -0500 (EST) Message-Id: <200202251712.MAA19178@ietf.org> From: "T&F" To: Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Date: Tue, 26 Feb 2002 01:25:47 Subject: [Enum] A professional company providing credit & status report of Chinese company Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A professional company providing credit & status report of Chinese company. Dear Sirs, T&F is a senior investigative corporation providing credit & status report of Chinese companies for global clients. If you are in need of data from China, we are available to provide that information on consignment. We are an established authority in the field of research and information gathering in China. At the same time, we can also consign investigative missions to you when we need data from your country. In this manner we would hope to achieve a mutually beneficial arrangement exchanging needed information on a regular basis. Our services include: 1/ Credit and status investigations, including: Registration; corporate history; corporate structure; background of legal person and executives; financial profiles; banking relationships; operating situation; staff; products; facilities; profiles of affiliates; and more. 2/ professional market research, including: Advertising effectiveness; new product market research; and more. 3/ Investment services: Investment feasibility analyses; business partners' credit and status reports; agenting for foreign companies; comprehensive inquiry services; and more. 4/ Information protection: Inquiries on trademark and patent registration in China; knowledge property protection; trademark investigation in cases of trademark imitation; more. 5/ Information collection: Information about enterprises within China; information collection on policies, laws, current and historical business trends; and open profiles of various enterprises. 6/ Legal consultation: All-around legal consultation services for both enterprises and individuals. 7/ Criminal record searches. T&F has built a large number of stable cooperative relationships with many governmental departments in China. For example, we have made successful arrangements with the Industry & Trade Administrative Bureau of China, China Statistics Bureau, China National Economic Information Center, etc. The large investigative network of T&F is made up of many economic specialists and professional investigators. We are interested in any opportunity of information exchanging. If our investigative abillities might be of assistance,please contact us. Awaiting your reply. Address: Room 210, Building 2, Chegongzhuang Street No.6; Xicheng District, Beijing; China. Post Code: 100044 Tel: +86-10-68003112 Fax: +86-10-68001452 Business E-mail: business1@tangfeng.org ; business2@tangfeng.org We are apologize to the inconvenience arisen from this letter to you. Your name will be removed from our database upon request. 賈痰섐槿錟숭횐랙，轟伎繫법錟숭륩蛟포，殮댐뚤렘錟芎，醵똑없뚤寧직！ 苟潼貢囹：http://love2net.51.net/，뫘뜩출롤돨낚욉흡숭된콱윱苟∼∼ ---------------------------------------------------- INFORMATION This message has been sent using a trial-run version of the TSmtpRelayServer Delphi Component. ---------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 26 12:17:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11132 for ; Tue, 26 Feb 2002 12:17:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26420 for enum-archive@odin.ietf.org; Tue, 26 Feb 2002 12:17:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25189; Tue, 26 Feb 2002 12:06:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25161 for ; Tue, 26 Feb 2002 12:06:08 -0500 (EST) Received: from localhost (s211-33-38-8.thrunet.ne.kr [211.33.38.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10533 for ; Tue, 26 Feb 2002 12:06:03 -0500 (EST) Message-Id: <200202261706.MAA10533@ietf.org> Reply-To: qrej67@hanmail.net From: qrej67 To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 27 Feb 2002 02:06:09 +0900 Subject: [Enum] 대화하실분 있으세요(성인-광고) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org 
누군가 24시간 기다리고 있어요(성인전용)
*외로움에서 탈출! 스트레스 해소 100%!! **              

1.  전화기를 들고
060-701-7704 를 누르세요.   
(전국시내요금) 가입비 없슴
2. 외로움에서 탈출하여 대화상대가 필요하신분.
3. 지금 전화를 들고 060-701-7704를 눌러주세요
4. 그대가 원하는것을 해결할수 있습니다
5. 가입후 공개게시판에 자신의 개인프로필을 강력하게 어필해보세요

그 다음에 무슨일이 일어날지 책임못져

죄송합니다
본 메일은 정보통신망 이용촉진법 규정에 따라 광고메일임을 표시하였으며 
수신거부장치를 마련하고 있습니다. 

본메일주소는 인터넷상에서 취득한것이며 메일주소외 어떠한 개인정보도 갖고 있지 않습니다
원치 않은 정보였다면 정중히 사과 드리며, 
수신거부를 해 주시면 다음부터는 메일이 발송되지 않을 것입니다
수신거부									(30/100)
_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Feb 26 17:27:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23544 for ; Tue, 26 Feb 2002 17:27:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25203 for enum-archive@odin.ietf.org; Tue, 26 Feb 2002 17:27:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24866; Tue, 26 Feb 2002 17:18:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24826 for ; Tue, 26 Feb 2002 17:18:25 -0500 (EST) Received: from localhost ([211.217.173.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23390 for ; Tue, 26 Feb 2002 17:18:20 -0500 (EST) Message-Id: <200202262218.RAA23390@ietf.org> Reply-To: gotours@dreamwiz.com From: 여행가자 To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 27 Feb 2002 07:15:44 +0900 Subject: [Enum] [이벤트광고]무료 회원가입 하시면 해외 무료 여행권을 드립니다. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org 여행가자 오픈 기념으로 회원 가입시 [태국,필리핀,사이판] 무료 해외 여행권을 드립니다.


[이벤트1] = 여행가자 홈페이지 오픈 기념으로 회원 가입시 [태국,필리핀,사이판]
무료 해외 여행권을 드립니다.   [항공권 별도 ]
기간 : 2002년 2월18일 ~ 4월 30일 까지 대상 : 여행가자 신규회원 가입자 전원증정

[이벤트2] = 주위의 결혼하시는 분들에게 저희 여행가자를 소개시켜 주셔서 신혼여행이 
계약되면 계약과 동시에 계좌로 일금 50,000원을 입금해 드립니다.
(단 제주도 신혼여행은 20,000원) 
 여행가자 홈페이지 바로가기
 

귀하의 승락없이 홍보성 전자 우편을 보내게 된 점 정중히 사과 드립니다.
정보통신망이용촉진법 규정을 준수하여 광고메일임을 표시하였으며, 수신거부 장치를 마련하고 있습니다.
귀하의 전자 우편 주소는 인터넷 상의 공개된 장소에서 습득하였으며, 저희는 귀하의 전자우편 주소 외 어떠한 개인정보도 가지고 있지 않으므로 안심하시기 바랍니다. 수신을 원치 않으시면 를 클릭해 주십시요.  

 
_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 27 04:49:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15156 for ; Wed, 27 Feb 2002 04:49:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA07149 for enum-archive@odin.ietf.org; Wed, 27 Feb 2002 04:49:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06413; Wed, 27 Feb 2002 04:37:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06371 for ; Wed, 27 Feb 2002 04:37:29 -0500 (EST) Received: from t-6mnjnqs5jxuuc ([211.152.107.30]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14889 for ; Wed, 27 Feb 2002 04:37:21 -0500 (EST) Message-Id: <200202270937.EAA14889@ietf.org> From: "T&F" To: Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Date: Wed, 27 Feb 2002 17:50:34 Subject: [Enum] A professional company providing credit & status report of Chinese company Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A professional company providing credit & status report of Chinese company. Dear Sirs, T&F is a senior investigative corporation providing credit & status report of Chinese companies for global clients. If you are in need of data from China, we are available to provide that information on consignment. We are an established authority in the field of research and information gathering in China. At the same time, we can also consign investigative missions to you when we need data from your country. In this manner we would hope to achieve a mutually beneficial arrangement exchanging needed information on a regular basis. Our services include: 1/ Credit and status investigations, including: Registration; corporate history; corporate structure; background of legal person and executives; financial profiles; banking relationships; operating situation; staff; products; facilities; profiles of affiliates; and more. 2/ professional market research, including: Advertising effectiveness; new product market research; and more. 3/ Investment services: Investment feasibility analyses; business partners' credit and status reports; agenting for foreign companies; comprehensive inquiry services; and more. 4/ Information protection: Inquiries on trademark and patent registration in China; knowledge property protection; trademark investigation in cases of trademark imitation; more. 5/ Information collection: Information about enterprises within China; information collection on policies, laws, current and historical business trends; and open profiles of various enterprises. 6/ Legal consultation: All-around legal consultation services for both enterprises and individuals. 7/ Criminal record searches. T&F has built a large number of stable cooperative relationships with many governmental departments in China. For example, we have made successful arrangements with the Industry & Trade Administrative Bureau of China, China Statistics Bureau, China National Economic Information Center, etc. The large investigative network of T&F is made up of many economic specialists and professional investigators. We are interested in any opportunity of information exchanging. If our investigative abillities might be of assistance,please contact us. Awaiting your reply. Address: Room 210, Building 2, Chegongzhuang Street No.6; Xicheng District, Beijing; China. Post Code: 100044 Tel: +86-10-68003112 Fax: +86-10-68001452 Business E-mail: business1@tangfeng.org ; business2@tangfeng.org We are apologize to the inconvenience arisen from this letter to you. Your name will be removed from our database upon request. 賈痰섐槿錟숭횐랙，轟伎繫법錟숭륩蛟포，殮댐뚤렘錟芎，醵똑없뚤寧직！ 苟潼貢囹：http://love2net.51.net/，뫘뜩출롤돨낚욉흡숭된콱윱苟∼∼ ---------------------------------------------------- INFORMATION This message has been sent using a trial-run version of the TSmtpRelayServer Delphi Component. ---------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 27 06:57:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17155 for ; Wed, 27 Feb 2002 06:57:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13770 for enum-archive@odin.ietf.org; Wed, 27 Feb 2002 06:57:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13290; Wed, 27 Feb 2002 06:48:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13253 for ; Wed, 27 Feb 2002 06:48:21 -0500 (EST) Received: from ameritech.net ([207.179.87.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16918 for ; Wed, 27 Feb 2002 06:48:15 -0500 (EST) Message-Id: <200202271148.GAA16918@ietf.org> From: "Information Management & Marketing, LLC" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 27 Feb 2002 06:46:53 -0800 Reply-To: "Information Management & Marketing, LLC" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Enum] Re:Qualified & Guaranteed Leads Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Dear Business Owner, General Manager, Sales Manager, I'd like to introduce you to perhaps one of the Security Industry's best kept secrets. Our cold calling professionals are helping burglar alarm, cctv & fire alarm providers all across the United States get the appointments they need to survive. We provide the lists, we make the calls, we qualify the calls and then we set your appointments. Our leads are not just another name on a list. When you get a lead from us it is with a bonafide prospect who has been qualified according to YOUR standards, who is interested in YOUR services and would like to meet with one of YOUR sales representatives. My partner Rex and I have several combined years experience working in the security alarm industry as sales representatives. We learned long ago just how valueable an appointment with a qualified and interested prospect really was. Over the years we became experts at generating leads for burglar alarm companies via the telephone. At the end of this letter I have included the script we use to generate appointments as well as our "Overcoming Common Objections" worksheet. We have had huge success using these tools and we are offering them to you in the hopes that you will also find them useful for your own campaign. If you do not have the time or personnel to run your own appointment setting campaign and would like additional information concerning our services please feel free to call us at 517-664-2631 or visit our web site at www.imm-marketing.com. Either way we would be more than happy to answer any questions you may have concerning our services. Sincerely, Matthew LaClear CEO Information Management & Marketing, LLC ____________________________________________________________________________ __________________ If you have received this e-mail by error or would like to be removed from our mailing list simply hit reply and type remove and we will respectfully remove you from our lists immediately. Be sure to include the e-mail address you would like removed. ____________________________________________________________________________ __________________ Burglar Alarm Telemarketing Script QUALIFY Hello, am I speaking to the person in charge of security for the business? (GO TO INTRODUCTION) INTRODUCTION My name is _____________ and I'm calling from ABC Security. If I can show you a way to protect your business assets could you take a few minutes to listen further? (GO TO PROBING QUESTION) PROBING QUESTION Have you had any problems with shop lifting, employee theft or break-ins? (IF YES GO TO SALES PITCH A) SALES PITCH A We're a locally owned company who specializes in protecting businesses like yours. We specialize in Burglar and Fire Alarm Systems, as well as surveillance cameras and Access Control. We sure would like to come out and show you how we can immediately begin helping your business protect itself. Could we come over sometime in the next couple of days? (IF YES SCHEDULE APPOINTMENT) (IF NO GO TO REBUTTAL QUESTION) Rebuttal Question Just out of curiosity, how are you presently protecting your business from theft and fire? (Go to final attempt to close) Final Attempt to Close As devastating to your business's finances as theft and fire can be, can you see where a short 20 minute visit with my representative can turn out to be a good investment of your time? (If yes schedule appointment) (If no end call politely) ____________________________________________________________________________ __________________ If prospect offers following objections respond accordingly. If they tell you they are not interested go to the rebuttals. Remember the majority of sales made every year were made with prospects that initially were not interested when they were called upon. Otherwise they would have been the ones calling us!!!! "I can't afford it" You know I can definitely appreciate the way you feel. In fact others have also felt the same way you feel. But what we've found is that once they actually spoke with a rep. From our company and found out what our system really costs they realized that they really couldn't afford being without our help. Should I send the rep. Over to see you tomorrow or the day after? "I have a system with another company" I understand fully how you feel you are properly taken care of. In fact others felt the same way too. But what found is that our company can compliment your current system, and maybe even save you money. Should I send the rep over to see you tomorrow of the day after? "That's what I have insurance for" That's fine for the things you can replace. But insurance won't protect your business from employee time theft and other hidden losses your business faces every day: Should I send the rep over to see you tomorrow of the day after? Rebuttal Questions (go to close after each no answer to below questions) 1. Were you aware that every day businesses lose $70 million to theft? Is your business protected from theft? 2. The #1 reason for shoplifting is that it's easy and there's little or no risk involved? Is your business protected from shoplifting? 3. More and more, businesses need to protect against lawsuits and fake insurance claims brought by customers as well as employees. Is your business protected from false lawsuits and insurance fraud? 4. Delivery shortages are very common. Is your business protected from vendor theft? 5. Otherwise honest employees stole $160 billion last year by wasting time on the job. Is your business protected from employee time theft? 6. The average poor customer service incident results in the minimum of 10 customers. Is your business protected against poor customer service? 7. Would you be interested in protecting your business against fire? 8. Would you be interested in saving up to 20% on your property insurance? SET THE APPOINTMENT ____________________________________________________________________________ __________________ If you have received this e-mail by error or would like to be removed from our mailing list simply hit reply and type remove and we will respectfully remove you from our lists immediately. Be sure to include the e-mail address you would like removed. ____________________________________________________________________________ __________________ _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 27 07:31:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19164 for ; Wed, 27 Feb 2002 07:31:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16225 for enum-archive@odin.ietf.org; Wed, 27 Feb 2002 07:31:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15124; Wed, 27 Feb 2002 07:22:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15092 for ; Wed, 27 Feb 2002 07:22:52 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17694; Wed, 27 Feb 2002 07:22:48 -0500 (EST) Message-Id: <200202271222.HAA17694@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 27 Feb 2002 07:22:48 -0500 Subject: [Enum] I-D ACTION:draft-brandner-enum-tel-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : 'The ENUM 'tel' enumservice' Author(s) : R. Brandner, L. Conroy Filename : draft-brandner-enum-tel-00.txt Pages : 11 Date : 26-Feb-02 This document describes the enumservice 'tel' and how it is used with an ENUM application when indicated within a returned a NAPTR record. It gives guidelines for the treatment of records having this sub-field value, and for the onward processing of information gleaned from the enclosing NAPTR record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enum-tel-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-brandner-enum-tel-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-brandner-enum-tel-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020226130252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brandner-enum-tel-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brandner-enum-tel-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020226130252.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 27 14:06:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10771 for ; Wed, 27 Feb 2002 14:06:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21462 for enum-archive@odin.ietf.org; Wed, 27 Feb 2002 14:06:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20212; Wed, 27 Feb 2002 13:57:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20181 for ; Wed, 27 Feb 2002 13:57:23 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10157 for ; Wed, 27 Feb 2002 13:57:19 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA01934 for ; Wed, 27 Feb 2002 19:57:17 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id TAA26675 for ; Wed, 27 Feb 2002 19:57:09 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id <1J4RASMX>; Wed, 27 Feb 2002 19:57:20 +0100 Message-ID: From: Brandner Rudolf To: enum@ietf.org Cc: Conroy Lawrence Date: Wed, 27 Feb 2002 19:57:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Enum] Common Issues with ENUM and enumservices Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org There seems to be a missing element to the documents as proposed in 2916bis. Maybe there's room for another document, giving general issues that are common either to the use of existin DNS features or to all enumservices. This SHOULD NOT discuss which tree within the DNS forest should hold ENUM NAPTRs. Single question to the list - should there be another document tied with these others that describes these items? Background: While writing the tel enumservice draft, we realized, that there were some possible uses of DNS that were related. For example, a CNAME could be used to represent a forwarding service. However, some issues with the use of a CNAME RR within e164.arpa are not really tied to the tel enumservice at all. Instead, they are common to all enumservices (and potentially general to all uses of NAPTRs). Also, while looking at the overall service that could be provided, we considered data to be held in other trees of the DNS (please note - this is NOT intended to trigger another "use my TLD" blast of hot air, my air-conditioning bill for reading this list has already exceeded this year's budget). For example, a NAPTR (*not* using the ENUM service) could store useful data, which could also be used by a client of ENUM when dealing with the returned enumservice. An example we gave were for storage of service provider contact info (e.g. phone number) or prefix dial string. In addition, we considered how to report a broken listing and CLI my not give an immediately useful identifier. Finally, we wondered about priority/preference and order. A suggestion was made, that a particular enumservice should have precedence over another, or there should be only one NAPTR. What is the resolution process if more than one enumservice document makes the same stricture? All of these issues are not unique to the tel enumservice and they haven't to do with the base procedures of 2916bis or the proceures described in the DDDS documents, hence the question. Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 27 14:06:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10791 for ; Wed, 27 Feb 2002 14:06:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21477 for enum-archive@odin.ietf.org; Wed, 27 Feb 2002 14:06:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20247; Wed, 27 Feb 2002 13:57:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20218 for ; Wed, 27 Feb 2002 13:57:29 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10161 for ; Wed, 27 Feb 2002 13:57:25 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA05661; Wed, 27 Feb 2002 19:57:18 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id TAA26674; Wed, 27 Feb 2002 19:57:09 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id <1J4RASMW>; Wed, 27 Feb 2002 19:57:20 +0100 Message-ID: From: Brandner Rudolf To: enum@ietf.org Cc: "'zmolek@avaya.com'" , Conroy Lawrence Subject: Re: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Date: Wed, 27 Feb 2002 19:57:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Here some comments on draft-zmolek-enum-pointer-00: There are reasonable concerns over the length of time it takes to resolve to a specific communications service and contact address, when using ENUM. There have also been some concerns over the generality that DNS is a public service and so provides data to whomever requests it. Use of an enum-pointer doesn't seem to address the former problem; it adds another lookup to the process, and suggests that this should not use DNS. It may address the latter problem, but there are two assumptions that seem to be embedded. First, it is *assumed* that there will be service field tags used to report codec capabilities and transcoding. This is by no means a unanimous position, and concerns with such constructs as "+E2UVIDEO-G.263" or "+E2UVOICE-G7.11" have been raised on the list. Secondly, the idea of service resolution service proposed seems to tie in with "presence", which I take to mean with current connectivity or location; there seems to be a suggestion that this is not addressed using the scheme proposed in the sipping-E.164 draft. As far as I understand it, the proposed sip enumservice is intended to deal with the further service resolution in exactly the same way as that redirected via the enum-pointer. Could you please explain how the sip enumservice as described differs from a service resolution service redirected via the enum-pointer? If the intent of this proposal is instead to take the service resolution service completely outside of the IP world (e.g. a URI indicating connection to a PSTN-based gateway, such as existing Servcice Nodes) then this is not clear from the draft. I think the next version might propose the scheme intended - the URI held in the NAPTR should trigger some sort of association, but it is unclear what exactly the pres enumservice involves. In the last sentence of the penultimate paragraph of section 5, it is stated that "the ENUM registrant may choose to have presence, policy, and privacy services provided by their ENUM registrar". It seems to me that the ENUM registrant can take these from their 'service resolution service provider'; this need not be their ENUM registrar. As stated, this appears to be an undue limitation. Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 27 14:41:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13208 for ; Wed, 27 Feb 2002 14:41:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23854 for enum-archive@odin.ietf.org; Wed, 27 Feb 2002 14:41:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23423; Wed, 27 Feb 2002 14:33:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23391 for ; Wed, 27 Feb 2002 14:33:12 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12575 for ; Wed, 27 Feb 2002 14:33:08 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1RJWc809368; Wed, 27 Feb 2002 14:32:38 -0500 Message-Id: <5.1.0.14.2.20020227141042.02536e60@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Feb 2002 14:35:15 -0500 To: Brandner Rudolf , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Cc: "'zmolek@avaya.com'" , Conroy Lawrence In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 07:57 PM 2/27/2002 +0100, Brandner Rudolf wrote: >Here some comments on draft-zmolek-enum-pointer-00: > >There are reasonable concerns over the length of time it takes to resolve >to a specific communications service and contact address, when using ENUM. >There have also been some concerns over the generality that DNS is a >public service and so provides data to whomever requests it. Before we condemn the DNS do we have any statistics to back up that contention? Eventually we need this in the process to documenting taking 2916 from Proposed to Draft Standard. Why is this any different from a ENUM to SIP look up where first is the translation is TN to SIP URL and then URL to SIP SRV record? If the suggestion is that this is increasing call setup times then I'd certainly like to see some statistics supporting the contention. If DNS data is on multiple hops then there are certainly issues ..but these are highly related to network configuration not the DNS and unfortunately we have never discusses caching issues. I would be willing to suspect that most calls are to a limited defined number of endpoints ..maybe 50% of all calls from a specific endpoint are to a list of no more than 50 numbers etc... this leads me to believe that caching again mitigates those issues. How could it be any worse than current cellular call setups? >Use of an enum-pointer doesn't seem to address the former problem; it adds >another lookup to the process, and suggests that this should not use DNS. I do respectfully disagree... I will trade call setup timing for personal privacy and security thank you. Which is why I actually have a problem with your draft ..enum-bradner :-) Essentially you have proposed a call forwarding service using TEL URL's ... my question is why? Why would I want to expose that information in the global DNS vs offered as a service from either my PSTN or SIP service provider where 1. my personal preferences are hidden from global view and 2. both the PSTN and SIP are better tools dynamic updates in real time? >It may address the latter problem, but there are two assumptions that seem >to be embedded. >First, it is *assumed* that there will be service field tags used to >report codec capabilities and transcoding. This is by no means a unanimous >position, and concerns with such constructs as "+E2UVIDEO-G.263" or >"+E2UVOICE-G7.11" have been raised on the list. I do NOT assume that except in the case of FAX where there is no negotiation capable in the protocol (SMTP) ... that does lead me to think there is a future for RESCAP and NAPTR records for certain types of services. But I can be educated ... I really objected to the Ranalli draft on the basis that adding to much granularity to service fields places too much burden of the capabilities of the C/UA resolver. The zmolek draft has started me to thinking there are conditions that granularity is reasonable ..except I would now require an Applicability / Justification Statement in the IANA registration document that places a burden of proof on the protocol registrant that there is "no other way" to do this...etc. >Secondly, the idea of service resolution service proposed seems to tie in >with "presence", which I take to mean with current connectivity or >location; there seems to be a suggestion that this is not addressed using >the scheme proposed in the sipping-E.164 draft. >As far as I understand it, the proposed sip enumservice is intended to >deal with the further service resolution in exactly the same way as that >redirected via the enum-pointer. >Could you please explain how the sip enumservice as described differs from >a service resolution service redirected via the enum-pointer? Or in other words why is presence itself distinct from SIP. I'd like a description of that myself. >If the intent of this proposal is instead to take the service resolution >service completely outside of the IP world (e.g. a URI indicating >connection to a PSTN-based gateway, such as existing Servcice Nodes) then >this is not clear from the draft. I think the next version might propose >the scheme intended - the URI held in the NAPTR should trigger some sort >of association, but it is unclear what exactly the pres enumservice involves. You are not suggesting we go down the ENUM vs TRIP route are you ? :-) >In the last sentence of the penultimate paragraph of section 5, it is >stated that "the ENUM registrant may choose to have presence, policy, and >privacy services provided by their ENUM registrar". It seems to me that >the ENUM registrant can take these from their 'service resolution service >provider'; this need not be their ENUM registrar. As stated, this appears >to be an undue limitation. I dont see the problem here ... the ENUM registrar and the service resolution provider {tier 2] may or may not be the same entity. >Rudi > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Feb 27 17:19:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22048 for ; Wed, 27 Feb 2002 17:19:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03962 for enum-archive@odin.ietf.org; Wed, 27 Feb 2002 17:19:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03484; Wed, 27 Feb 2002 17:10:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03451 for ; Wed, 27 Feb 2002 17:10:29 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21562 for ; Wed, 27 Feb 2002 17:10:23 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g1RM90U14369 for ; Wed, 27 Feb 2002 17:09:00 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g1RM90N14352 for ; Wed, 27 Feb 2002 17:09:00 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" x-mimeole: Produced By Microsoft Exchange V6.0.4712.0 Subject: RE: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Date: Wed, 27 Feb 2002 15:11:02 -0700 Message-ID: Thread-Topic: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Thread-Index: AcG/xa4ln2gvEruPRza+U619Ti9xnwABjKFg From: "Zmolek, Andrew (Andrew)" To: "Richard Shockey" , "Brandner Rudolf" , Cc: "Conroy Lawrence" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA03452 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At long last, some discussion! If I understand you correctly, these seem to be your concerns: 1. DNS resolution latency is already a concern, why make it worse by adding a pointer? 2. Why add another layer of indirection when service resolution could take place directly? 3. Since codec capabilities are embedded in service field tags, why worry about negotiation? 4. Isn't it enough that SIP offers such a service resolution service for "presence" 5. Is a specific URI scheme or architecture being proposed here? 6. Why suggest that the ENUM service provider and service resolution service provider might be the same? Here's my take on the answers to each: 1. DNS resolution latency obviously must be kept within the range of human tolerance when sessions need to be established. But if there's truly a latency problem with adding service resolution pointers to ENUM in general, then SIP in particular would be unusable with ENUM. This topic of resolution latency is an interesting rathole, I suppose, but ultimately falls in the category of universal challenges to ENUM in general. 2. Adding a layer of indirection should only be done when the alternatives are more ugly, and I believe service resolution services are just such a case. Here's why: - The mapping of E.164 addresses to devices (or systems behind the devices) is not one-to-one today and is increasingly one-to-many for a given E.164 address (and many-to-many overall) - Not all systems and devices have or will have the same capabilities, even indirectly - Associations between devices and E.164 numbers can change more rapidly and frequently than the cache-friendly DNS system can support (consider the case of call forwarding today mapped against the large TTL of a DNS reply) Strong association of detailed service capabilities with E.164 numbers via ENUM would either: A. Reduce accuracy of resulting information by giving information only for ENUM-registered endpoints when one or more non-registered endpoints may ultimately terminate a call to a given E.164 number. B. Somehow forbid non-registered endpoints from terminating a call initiated through ENUM (bye-bye call forwarding!) C. Force ENUM service providers to act as a public "presence" service, updating service-tags and capabilities in real-time. Note that none of these options is desirable, and none tackles issues in the sphere of privacy, public exposure of information, hacking via service profiling, etc. So it is my assertion that for many cases a "service resolution" level of indirection is justified here. I am careful to note, however, that in some specific cases, no level of indirection is needed or desired--ENUM clearly has value in both cases. 3. Just because you can embed codec capabilities in service tags doesn't mean it's a good idea. In addition to the dynamic endpoints and capabilities problem I discuss in #2 above, there's the issue of service tag multiplication which gets even uglier when transcoding tags are used. If the resolution latency issue you raise is important to you, then I would think you would want to avoid the possibility of forcing a TCP session setup and teardown just because your service tag list won't fit in a UDP packet anymore. Does anything more really need to be said here? 4. Within the world that SIP encompasses (which is admittedly a lot), I have to say that SIP does a good job of acting as a service resolution pointer. I am very supportive of SIP as such, but that doesn't mean I believe that SIP-based presence is ready or willing to provide more general, signaling-protocol agnostic presence services. Just because SIP offers one approach to presence doesn't mean that it is useful to exclude others, even if they are not yet mature or fully formed. Frankly, many other presence services already exist within limited realms and all of them would benefit from an open protocol for interchange of that information. From the ENUM point of view, I would assert that we shouldn't be in the business of picking winners for presence services. Yet we should still make the bar reasonably high before assigning a service tag to such a service. 5. If it wasn't clear in the draft, let me make it perfectly clear here: I am not proposing a service tag or specific service. This is intentional, and although I did include some examples, they are not intended to form the basis of any proposal for a tag or a service. So what am I proposing? Mainly an examination of some critical issues we need to take into account as we consider how to deal with service tags, codec negotiation, "presence" services, and the like. I would submit that having a notion of "service resolution" services within the ENUM worldview allows us to make better decisions about what is allowable in service field tags and what belongs elsewhere. To be blunt, the availability of "service resolution" services, SIP-based or not, eliminates much of the previous justification for detailed and complex service field tags and may help us move on to more important topics. 6. Suggesting that the ENUM service provider might also provide presence services was my way of demonstrating that there's something in this for the ENUM service provider as well. But it was *JUST A SUGGESTION*, nothing more. For those that missed this in the draft, let me reinforce that there need not be any connection at all between the two beyond the service field tag and URI to point there. In fact, many large enterprises will probably do a presence service themselves, just as they do with their DNS services. Or they might outsource, just as they do with their DNS services. In summary, service resolution latency is important, there's a good reason for service resolution services, SIP's a reasonable (if not complete) example of such a service, and indeed there is a difference between providers of ENUM and service resolution services. Thanks again for your note. I'm looking forward to more conversation on these issues, as I think they get to the heart of the ENUM value proposition for all parties. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Richard Shockey [mailto:rich.shockey@NeuStar.com] Sent: Wednesday, February 27, 2002 12:35 PM To: Brandner Rudolf; enum@ietf.org Cc: Zmolek, Andrew (Andrew); Conroy Lawrence Subject: Re: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt At 07:57 PM 2/27/2002 +0100, Brandner Rudolf wrote: >Here some comments on draft-zmolek-enum-pointer-00: > >There are reasonable concerns over the length of time it takes to resolve >to a specific communications service and contact address, when using ENUM. >There have also been some concerns over the generality that DNS is a >public service and so provides data to whomever requests it. Before we condemn the DNS do we have any statistics to back up that contention? Eventually we need this in the process to documenting taking 2916 from Proposed to Draft Standard. Why is this any different from a ENUM to SIP look up where first is the translation is TN to SIP URL and then URL to SIP SRV record? If the suggestion is that this is increasing call setup times then I'd certainly like to see some statistics supporting the contention. If DNS data is on multiple hops then there are certainly issues ..but these are highly related to network configuration not the DNS and unfortunately we have never discusses caching issues. I would be willing to suspect that most calls are to a limited defined number of endpoints ..maybe 50% of all calls from a specific endpoint are to a list of no more than 50 numbers etc... this leads me to believe that caching again mitigates those issues. How could it be any worse than current cellular call setups? >Use of an enum-pointer doesn't seem to address the former problem; it adds >another lookup to the process, and suggests that this should not use DNS. I do respectfully disagree... I will trade call setup timing for personal privacy and security thank you. Which is why I actually have a problem with your draft ..enum-bradner :-) Essentially you have proposed a call forwarding service using TEL URL's ... my question is why? Why would I want to expose that information in the global DNS vs offered as a service from either my PSTN or SIP service provider where 1. my personal preferences are hidden from global view and 2. both the PSTN and SIP are better tools dynamic updates in real time? >It may address the latter problem, but there are two assumptions that seem >to be embedded. >First, it is *assumed* that there will be service field tags used to >report codec capabilities and transcoding. This is by no means a unanimous >position, and concerns with such constructs as "+E2UVIDEO-G.263" or >"+E2UVOICE-G7.11" have been raised on the list. I do NOT assume that except in the case of FAX where there is no negotiation capable in the protocol (SMTP) ... that does lead me to think there is a future for RESCAP and NAPTR records for certain types of services. But I can be educated ... I really objected to the Ranalli draft on the basis that adding to much granularity to service fields places too much burden of the capabilities of the C/UA resolver. The zmolek draft has started me to thinking there are conditions that granularity is reasonable ..except I would now require an Applicability / Justification Statement in the IANA registration document that places a burden of proof on the protocol registrant that there is "no other way" to do this...etc. >Secondly, the idea of service resolution service proposed seems to tie in >with "presence", which I take to mean with current connectivity or >location; there seems to be a suggestion that this is not addressed using >the scheme proposed in the sipping-E.164 draft. >As far as I understand it, the proposed sip enumservice is intended to >deal with the further service resolution in exactly the same way as that >redirected via the enum-pointer. >Could you please explain how the sip enumservice as described differs from >a service resolution service redirected via the enum-pointer? Or in other words why is presence itself distinct from SIP. I'd like a description of that myself. >If the intent of this proposal is instead to take the service resolution >service completely outside of the IP world (e.g. a URI indicating >connection to a PSTN-based gateway, such as existing Servcice Nodes) then >this is not clear from the draft. I think the next version might propose >the scheme intended - the URI held in the NAPTR should trigger some sort >of association, but it is unclear what exactly the pres enumservice involves. You are not suggesting we go down the ENUM vs TRIP route are you ? :-) >In the last sentence of the penultimate paragraph of section 5, it is >stated that "the ENUM registrant may choose to have presence, policy, and >privacy services provided by their ENUM registrar". It seems to me that >the ENUM registrant can take these from their 'service resolution service >provider'; this need not be their ENUM registrar. As stated, this appears >to be an undue limitation. I dont see the problem here ... the ENUM registrar and the service resolution provider {tier 2] may or may not be the same entity. >Rudi > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Feb 28 05:12:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16042 for ; Thu, 28 Feb 2002 05:12:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA18484 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 05:12:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18000; Thu, 28 Feb 2002 05:02:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17966 for ; Thu, 28 Feb 2002 05:02:07 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15830 for ; Thu, 28 Feb 2002 05:02:02 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.224]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g1SA1utR022813; Thu, 28 Feb 2002 11:01:58 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Feb 2002 10:41:46 +0100 Message-ID: From: "Stastny, Richard" To: "'Brandner Rudolf'" , "'enum@ietf.org'" Cc: Conroy Lawrence Subject: RE: [Enum] I-D ACTION:draft-brandner-enum-tel-00.txt Date: Thu, 28 Feb 2002 10:41:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Rudi, here they are: I have some comments to your draft-brandner-enum-tel-00.txt: In Section 3. 'tel' sub-field definition it is stated: _When used with an ENUM application, a NAPTR record including the indicator 'tel' in the enumservice sub-field implies that the URI can be treated as formatted according to [9], and includes a telephone number. This implies that the communications service described by this record will require a telephone connection to be made._ The last sentence implies, that _in any case_ a client taking this NAPTR record into account needs already a subscription to a Service Provider providing access to a telephony service based on E.164 numbers natively. If not, the E2U+tel service shall be ignored. My carefull wording should induce, that the service provider not necessary need to have a gateway to the GSTN, but in most cases this may apply. But since E.164 numbers may also terminate on IP, this is not restricted to GSTN only. I also assume, that the phone number supplied should different from the original AUS, because this would create a loop in the first place. So the primary use of tel is to point the client to another number then the original AUS for some reason, if he intends to make a phone call to the GSTN anyway. Possible applications I see is e.g. Freephone and NP services, i.e. replacement of simple IN services. IMHO the last sentence also implies, that a _telephone_ connection SHALL be made in any case (not a voice connection). I am now coming to section 4.3 Use of tel for Redirection Services. First, I do not see much sense to point to much around anyway, with the danger of creating loops. My second point is: What happens, if the redirected to entry does not contain a tel service? Is than a other voice service to be used, or is the last tel service to be used to make a telephone connection? My proposal is: If the full ENUM entry is redirected to another E.164 number, CNAME shall be used. The tel service shall be used only to force a call via the phone network, that is, using the E.164 number supplied, if and only if the client has access to the phone network. This implies, that no additional query is made to ENUM for the number provided by the tel service from THIS client. This does not prevent another client (e.g. the client of the used phone service provider) to query ENUM again (getting an answer or not). A compromise between the two views would be to provide an indicator in the regexp, to indicate if the retrieved tel: is terminal or onother regarding another ENUM query may be made. How to do this I leave to the experts of regexp, because I am not. I have two additional problems: 1. Section 4.1 Locality of the caller the phone-context=+1 parameter SHALL not be used in ENUM (public ENUM) in any case, although I see the usability in private ENUM applications. 2. Section 4.2 TSP parameter. I have some problems with the TSP parameter. First the SHOULD should be definetely MAY. The other implicationes definitely require more study, because in the GSTN there may be carrier selection by the calling party, but the implications on routing on the GSTN if the calling party or the transit network know the destination network are to far reaching to be answered immediately. Also there has to be some standardisation on the information retrived. best regards Richard Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Feb 28 07:18:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18776 for ; Thu, 28 Feb 2002 07:18:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA24569 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 07:18:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24110; Thu, 28 Feb 2002 07:08:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24015 for ; Thu, 28 Feb 2002 07:08:29 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18378; Thu, 28 Feb 2002 07:08:25 -0500 (EST) Message-Id: <200202281208.HAA18378@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 28 Feb 2002 07:08:25 -0500 Subject: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : The E.164 to URI DDDS Application Author(s) : P. Faltstrom, M. Mealling Filename : draft-ietf-enum-rfc2916bis-00.txt Pages : 17 Date : 27-Feb-02 This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC WWWW. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC WWWW. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2916bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-rfc2916bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020227125417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-rfc2916bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-rfc2916bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020227125417.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 09:58:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26545 for ; Thu, 28 Feb 2002 09:58:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04273 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 09:58:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03739; Thu, 28 Feb 2002 09:48:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03685 for ; Thu, 28 Feb 2002 09:48:40 -0500 (EST) Received: from cjstls3 ([61.38.87.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25877 for ; Thu, 28 Feb 2002 09:48:34 -0500 (EST) Message-Id: <200202281448.JAA25877@ietf.org> Reply-To: cjstls3@hotmail.com From: 운산 To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Feb 2002 23:50:41 +0900 Subject: [Enum] [광고]여러분의 잃어버린 행복의 복까지 찾아드립니다. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org
운산운세정보
본 메일은 정보통신부 권고사항에 의거,제목에 [광고]란이 표시된 메일입니다.
허락없이 광고메일을 보내드려 죄송하며,정중히 양해 바랍니다.
메일주소는 게시판,동호회등의 공개 메일주소를 수집하여, 다른 개인정보는 없음을 알려드립니다.

운산운세정보에서는 다른 실시간상담업체와 달리 많은 상담선생님을 초빙하지 않고, 회사의 엄격한 기준에 부합된 상담선생님들만 모셔서 24시간 1:1 상담이 될 수 있도록 하였습니다. (홈페이지로 이동,무료상담실 운영)

직업운, 시험운, 진학운, 애정운, 사랑운, 건강운, 사업운, 꿈해몽, 토정비결, 속궁합 겉궁합, 승진운, 작명, 택일, 사주팔자, 풍수지리...
     
   
 
1.
 지역번호 없이(휴대폰 포함) 060-700-8865번으로 전화를 겁니다(전국단일요금)
2.


 1번을 누르시면 대기중인 상담선생님과 자동연결되고, 2번을 누르시고 원하는 상담선생님 고유번호를 누르시면 선택한 역술상담선생님과 통화할 수 있습니다. 이용중 문의 사항이나 불편사항은 이메일로 연락주시기 바랍니다.
 
     
   
  상담하실 내용을 미리 마음속으로 정리를 하거나 메모를 해 보세요.
그리고 상담선생님과 연결이 되면 상담하실 내용을 차근차근 설명을 하시면 보다 편리하게 상담을 하실 수 있을 겁니다. 상담내용은 일체 비밀이므로, 편안한 마음과 자세로 상담 해보세요.		  
     
   
  서비스 이용요금은 사용 후, 익월에 사용한 내역이 정보이용료 사용하신 전화요금에 함께 청구되도록 되어 있어 결재시 불편함이 없습니다.  
   

           "역학은 통계에 의한 과학적인 학문입니다"
                   Copyright (c) 2002 운산운세정보 All rights reserved 		 
(사)한국전화정보통신협회 심의필번호 200112-223          불건전 정보신고 ☎080-700-3700
이 메일의 수신을 원하지 않으시면 수신거부 를 눌러 주세요.
_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 11:18:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01184 for ; Thu, 28 Feb 2002 11:18:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09452 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 11:18:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08961; Thu, 28 Feb 2002 11:09:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08930 for ; Thu, 28 Feb 2002 11:09:15 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00616 for ; Thu, 28 Feb 2002 11:09:08 -0500 (EST) Received: from [193.118.192.40] ([193.118.192.40] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062961; Thu, 28 Feb 2002 16:09:09 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: Date: Thu, 28 Feb 2002 16:09:08 +0000 To: richard.stastny@oefeg.at From: Lawrence Conroy Cc: enum@ietf.org, Rudi Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: Richard Stasny's review of brandner-enum-tel Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Richard, Folks, First, thanks for reading the draft. Second... * The comment on ss 3 is good. There are many ways that one could use tel: URIs within NAPTRs. Even within the case of using NAPTRs for the 'tel' enumservice, there are a number of uses. What we said (in effect) was "The 'tel' enumservice indicates that the constructed URI *will* have the scheme "tel:", and this can be used to initiate a telephone call". As you suggest, "What the President meant to say was:" "The 'tel' enumservice indicates that the constructed URI *will* have the scheme "tel:" and that this can be used to initiate a call using a telephony service based on E.164 numbers natively. By implication, the caller must already have a subscription to a service provider that allows them access to such a service, or the result of processing with this record should be ignored". I like this re-phrasing, as it is more precise *and* more general. Much appreciated. Re. your further comments on this service, I'm still thinking about them - it *is* complex. * The comments on ss4.1 is well taken. As the (public) ENUM entries SHOULD be a full "global_phone_subscriber" number (i.e. an E.164 number) there is no need to have a phone-context. Adding a sentence to spell out SHOULD NOT use ";phone-context=" in case of a "tel:" URI with a full E.164 number is fine. Will add. BTW, I am a little concerned that we exclude 1-800 numbers that are only "dialable" from a given region, if we make the E.164 number a MUST which is why it's a SHOULD (and use of phone-context will be a SHOULD NOT). I'm not sure if this is a problem, so would appreciate anyone's comments on this. * Comments on ss4.2 (TSP parameter) - agreed(ish) Agreed, it is very complex. It is made more complex by not knowing where to introduce any such "profile for use" issues. I think it should be in ENUM as it's an operational feature for the whole system, so... Please, gentle ADs and Co-Chairs, give "the benefit of the doubt" to this thread. Given that: This TSP information can be sensitive, so I'm happy to change the SHOULD to a MAY. Is this OK with you, Rudi? I do like the idea of using data in another part of the DNS forest to hold prefix-dial strings is useful for prefix or "on-demand" carrier selection, so I think that it's something I'd be loath to discourage. (i.e. not lower than MAY, please :) In terms of standardising the data format, this could WELL be another tel: URI, using a local_phone_subscriber number with a global phone context tag to indicate where the prefix can be used. Thus I think that the following works: . The information could be held in a NAPTR record under the Operator's ".at." domain - that seems a useful way of storing it, and in a useful place. If anyone has alternative proposals, please holler. I *do* have a question on whether or not this NAPTR or URI needs a tag to indicate that it's not a dialable number on its own. Any thoughts on this will be gratefully received. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 11:38:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02675 for ; Thu, 28 Feb 2002 11:38:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11274 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 11:38:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10395; Thu, 28 Feb 2002 11:30:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10364 for ; Thu, 28 Feb 2002 11:30:19 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02000 for ; Thu, 28 Feb 2002 11:30:14 -0500 (EST) Received: from [0.0.0.0] (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA15469; Thu, 28 Feb 2002 17:29:43 +0100 (MET) Date: Thu, 28 Feb 2002 11:28:38 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Brandner Rudolf , enum@ietf.org cc: Conroy Lawrence Subject: Re: [Enum] Common Issues with ENUM and enumservices Message-ID: <28603007.1014895718@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-27 19.57 +0100 Brandner Rudolf wrote: > There seems to be a missing element to the documents as proposed in > 2916bis. Maybe there's room for another document, giving general issues > that are common either to the use of existin DNS features or to all > enumservices. This SHOULD NOT discuss which tree within the DNS forest > should hold ENUM NAPTRs. I have some comments / questions...because I don't really get it. Sorry. > Single question to the list - should there be another document tied with > these others that describes these items? Maybe. > Background: > While writing the tel enumservice draft, we realized, that there were > some possible uses of DNS that were related. For example, a CNAME could > be used to represent a forwarding service. However, some issues with the > use of a CNAME RR within e164.arpa are not really tied to the tel > enumservice at all. Instead, they are common to all enumservices (and > potentially general to all uses of NAPTRs). If you have a CNAME with one owner, you can not at the same time have NAPTR with the same owner. Instead, you can have a NAPTR which reference to a different owner where the final NAPTR resides, by having an empty flag field. So, already today, you _can_ have a pointer from one record in one zone to a record in a different zone. Different zones, different administrative entities. Is your point the need for different entities for different NAPTR records? > Also, while looking at the overall service that could be provided, we > considered data to be held in other trees of the DNS (please note - this > is NOT intended to trigger another "use my TLD" blast of hot air, my > air-conditioning bill for reading this list has already exceeded this > year's budget). :-) > For example, a NAPTR (*not* using the ENUM service) could store useful > data, which could also be used by a client of ENUM when dealing with the > returned enumservice. An example we gave were for storage of service > provider contact info (e.g. phone number) or prefix dial string. Possible with specific enumservices from my point of view. Maybe them will also use tel: URI schemes? > In > addition, we considered how to report a broken listing and CLI my not > give an immediately useful identifier. Ok. > Finally, we wondered about priority/preference and order. A suggestion > was made, that a particular enumservice should have precedence over > another, or there should be only one NAPTR. What is the resolution > process if more than one enumservice document makes the same stricture? The priority/preference must be calculated over all NAPTR records with the same owner. I.e. it is calculated as part of the DNS resolution, and not the NAPTR resolution. > All of these issues are not unique to the tel enumservice and they > haven't to do with the base procedures of 2916bis or the proceures > described in the DDDS documents, hence the question. I have not described the priority/preference issues, and I have not described the (in-)ability of using CNAME, empty flag fields for NAPTR records etc because those are DNS issues, and not ENUM issues. Not saying I don't want to write about them. Just as an explanation. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 11:51:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03571 for ; Thu, 28 Feb 2002 11:51:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12272 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 11:51:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11550; Thu, 28 Feb 2002 11:41:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11519 for ; Thu, 28 Feb 2002 11:41:44 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02932 for ; Thu, 28 Feb 2002 11:41:40 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1SGfC831761 for ; Thu, 28 Feb 2002 11:41:12 -0500 Message-Id: <5.1.0.14.2.20020228112829.024c1508@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Feb 2002 11:43:49 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA11520 Subject: [Enum] IETF 53 ENUM WG Draft Agenda Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Based on private mail and the discussion on the list, this is the general direction I'm taking with the agenda. This is subject to change, of course. Its clear that we have three general areas of discussion ..1. are issues related to the update of 2916 which is the core WG document which needs much more discussion on the list. 2. the ongoing discussion over the service field documents which, though they look at different applications, are addressing similar problems and it may be useful to thread these discussions together 3. the other documents such as provisioning call flows etc that have been on the agenda before and are due for updating etc. I am still thinking about the order here ... There are other documents that relate to ENUM issues that will not be discussed since they are purely informational. Once again, the noted gentleman and scholar Mr Jay Hilton of Telcordia has agreed to scribe for us. Comments notes on errors and omissions are welcome ... IETF 53 ENUM WG Draft Agenda AGENDA BASHING (5 min) Scribe Introduction � Jay Hilton < applause > . NEW CHARTER REVIEW - Chair뭩 (5 Min) http://www.ietf.org/html.charters/enum-charter.html CORE DOCUMENT REVIEW (45 min ??) 2916bis Update - The E.164 to URI DDDS Application A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-00.txt SERVICE FIELD DOCUMENTS ( 1 Hour ??) The Use of ENUM by SIP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-01.txt ENUM Service Descriptions A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-walter-ranalli-enum-service-01.txt ENUM Service Resolution A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zmolek-enum-pointer-00.txt The ENUM TEL enumservice A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enum-tel-00.txt OTHER DOCUMENTS Extensible Provisioning Protocol and E.164 (5 min) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-e164-02.txt ENUM Call Flows (10 min?) draft-lind-enum-callflows-03.txt DOCUMENTS OF NOTE [ NOT ON AGENDA ] US ENUM Forum Overview A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-freilich-overview-enum-forum-00.txt History and Context of ENUM Operational Decisions A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iab-itu-enum-notes-00.txt Number Portability in the PSTN Status to Last Call ? draft-ietf-enum-e164-gstn-np-03.txt OPEN DISCUSSION >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 12:09:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05029 for ; Thu, 28 Feb 2002 12:09:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15070 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 12:09:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12744; Thu, 28 Feb 2002 11:59:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12715 for ; Thu, 28 Feb 2002 11:59:05 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04072 for ; Thu, 28 Feb 2002 11:58:59 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA02490; Thu, 28 Feb 2002 17:58:57 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA06140; Thu, 28 Feb 2002 17:58:49 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 17:59:01 +0100 Message-ID: From: Brandner Rudolf To: "'Richard Shockey'" , enum@ietf.org Cc: "'zmolek@avaya.com'" , Conroy Lawrence Subject: AW: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Date: Thu, 28 Feb 2002 17:58:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA12716 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Comments inline. > -----Urspr�ngliche Nachricht----- > Von: Richard Shockey [mailto:rich.shockey@NeuStar.com] > Gesendet: Mittwoch, 27. Februar 2002 20:35 > An: Brandner Rudolf; enum@ietf.org > Cc: 'zmolek@avaya.com'; Conroy Lawrence > Betreff: Re: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt > > > At 07:57 PM 2/27/2002 +0100, Brandner Rudolf wrote: > > >Here some comments on draft-zmolek-enum-pointer-00: > > > >There are reasonable concerns over the length of time it > takes to resolve > >to a specific communications service and contact address, > when using ENUM. > >There have also been some concerns over the generality that DNS is a > >public service and so provides data to whomever requests it. > > Before we condemn the DNS do we have any statistics to back up that > contention? Eventually we need this in the process to > documenting taking > 2916 from Proposed to Draft Standard. > > Why is this any different from a ENUM to SIP look up where > first is the > translation is TN to SIP URL and then URL to SIP SRV record? If the > suggestion is that this is increasing call setup times then > I'd certainly > like to see some statistics supporting the contention. If > DNS data is on > multiple hops then there are certainly issues ..but these are highly > related to network configuration not the DNS and > unfortunately we have > never discusses caching issues. I would be willing to suspect > that most > calls are to a limited defined number of endpoints ..maybe > 50% of all calls > from a specific endpoint are to a list of no more than 50 > numbers etc... > this leads me to believe that caching again mitigates those issues. > > How could it be any worse than current cellular call setups? > Ok. Others have commented about this on the list. > > >Use of an enum-pointer doesn't seem to address the former > problem; it adds > >another lookup to the process, and suggests that this should > not use DNS. > > I do respectfully disagree... I will trade call setup timing > for personal > privacy and security thank you. Which is why I actually have > a problem with > your draft ..enum-bradner :-) > Sorry, but I also do respectfully disagree with your disagreement here. Pointing off ENUM to something else won't make the issues disappear. Time and network traffic needed for the resolution and privacy kept will resurface there, regardless what the 'something else' might be. BTW: > your draft ..enum-bradner :-) Thanks for the flowers. It is very motivating that you think the draft has superior quality ;^) > Essentially you have proposed a call forwarding service using > TEL URL's ... > my question is why? Why would I want to expose that > information in the > global DNS vs offered as a service from either my PSTN or SIP service > provider where 1. my personal preferences are hidden from > global view and > 2. both the PSTN and SIP are better tools dynamic updates in > real time? > Let Lawrence comment on this one. > > >It may address the latter problem, but there are two > assumptions that seem > >to be embedded. > >First, it is *assumed* that there will be service field tags used to > >report codec capabilities and transcoding. This is by no > means a unanimous > >position, and concerns with such constructs as "+E2UVIDEO-G.263" or > >"+E2UVOICE-G7.11" have been raised on the list. > > I do NOT assume that except in the case of FAX where there is no > negotiation capable in the protocol (SMTP) ... that does lead > me to think > there is a future for RESCAP and NAPTR records for certain > types of services. > > But I can be educated ... I really objected to the Ranalli > draft on the > basis that adding to much granularity to service fields > places too much > burden of the capabilities of the C/UA resolver. The zmolek > draft has > started me to thinking there are conditions that granularity > is reasonable > ..except I would now require an Applicability / Justification > Statement in > the IANA registration document that places a burden of proof on the > protocol registrant that there is "no other way" to do this...etc. > This one I leave to Lawrence, too. > > >Secondly, the idea of service resolution service proposed > seems to tie in > >with "presence", which I take to mean with current connectivity or > >location; there seems to be a suggestion that this is not > addressed using > >the scheme proposed in the sipping-E.164 draft. > >As far as I understand it, the proposed sip enumservice is > intended to > >deal with the further service resolution in exactly the same > way as that > >redirected via the enum-pointer. > >Could you please explain how the sip enumservice as > described differs from > >a service resolution service redirected via the enum-pointer? > > Or in other words why is presence itself distinct from SIP. > I'd like a > description of that myself. > Agreed, here I am with you. > > >If the intent of this proposal is instead to take the > service resolution > >service completely outside of the IP world (e.g. a URI indicating > >connection to a PSTN-based gateway, such as existing > Servcice Nodes) then > >this is not clear from the draft. I think the next version > might propose > >the scheme intended - the URI held in the NAPTR should > trigger some sort > >of association, but it is unclear what exactly the pres > enumservice involves. > > You are not suggesting we go down the ENUM vs TRIP route are > you ? :-) > Absolutely not, that's what I'm afraid of, too > > >In the last sentence of the penultimate paragraph of section > 5, it is > >stated that "the ENUM registrant may choose to have > presence, policy, and > >privacy services provided by their ENUM registrar". It seems > to me that > >the ENUM registrant can take these from their 'service > resolution service > >provider'; this need not be their ENUM registrar. As stated, > this appears > >to be an undue limitation. > > I dont see the problem here ... the ENUM registrar and the service > resolution provider {tier 2] may or may not be the same entity. > I agree. My worry was the implication that the provider of mentioned services *is* the registrar. > >Rudi > > > >_______________________________________________ > >enum mailing list > >enum@ietf.org > >https://www1.ietf.org/mailman/listinfo/enum > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 > 1120 Vermont Ave NW Suite 400 Washington DC 20005 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 12:09:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05089 for ; Thu, 28 Feb 2002 12:09:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15120 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 12:09:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12832; Thu, 28 Feb 2002 11:59:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12802 for ; Thu, 28 Feb 2002 11:59:51 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04121 for ; Thu, 28 Feb 2002 11:59:33 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA22500; Thu, 28 Feb 2002 17:59:12 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA06243; Thu, 28 Feb 2002 17:59:07 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 17:59:18 +0100 Message-ID: From: Brandner Rudolf To: richard.stastny@oefeg.at Cc: enum@ietf.org, Conroy Lawrence Date: Thu, 28 Feb 2002 17:59:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA12803 Subject: [Enum] AW: Richard Stasny's review of brandner-enum-tel Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit First I'd like to thank Richard Stastny for reviewing our draft and the comments he made. Second, I'm happy with the Lawrence's answer. Rudi > -----Urspr�ngliche Nachricht----- > Von: Lawrence Conroy [mailto:lwc@roke.co.uk] > Gesendet: Donnerstag, 28. Februar 2002 17:09 > An: richard.stastny@oefeg.at > Cc: enum@ietf.org; Rudi > Betreff: Re: Richard Stasny's review of brandner-enum-tel > > > Hi Richard, Folks, > First, thanks for reading the draft. > > Second... > * The comment on ss 3 is good. > There are many ways that one could use tel: URIs within NAPTRs. Even > within the case of using NAPTRs for the 'tel' enumservice, there are a > number of uses. > > What we said (in effect) was "The 'tel' enumservice indicates that the > constructed URI *will* have the scheme "tel:", and this can be used to > initiate a telephone call". > > As you suggest, "What the President meant to say was:" > "The 'tel' enumservice indicates that the constructed URI *will* have > the scheme "tel:" and that this can be used to initiate a call using a > telephony service based on E.164 numbers natively. By implication, the > caller must already have a subscription to a service provider that > allows them access to such a service, or the result of processing with > this record should be ignored". > > I like this re-phrasing, as it is more precise *and* more > general. Much > appreciated. > > Re. your further comments on this service, I'm still thinking > about them > - it *is* complex. > > > * The comments on ss4.1 is well taken. > As the (public) ENUM entries SHOULD be a full > "global_phone_subscriber" > number (i.e. an E.164 number) there is no need to have a > phone-context. > > Adding a sentence to spell out SHOULD NOT use > ";phone-context=" in case > of a "tel:" URI with a full E.164 number is fine. Will add. > > BTW, I am a little concerned that we exclude 1-800 numbers that are > only "dialable" from a given region, if we make the E.164 > number a MUST > which is why it's a SHOULD (and use of phone-context will be a SHOULD > NOT). I'm not sure if this is a problem, so would appreciate anyone's > comments on this. > > > * Comments on ss4.2 (TSP parameter) - agreed(ish) > Agreed, it is very complex. > It is made more complex by not knowing where to introduce any such > "profile for use" issues. I think it should be in ENUM as it's an > operational feature for the whole system, so... > Please, gentle ADs and Co-Chairs, give "the benefit of the doubt" > to this thread. > > Given that: > This TSP information can be sensitive, so I'm happy to change > the SHOULD > to a MAY. > Is this OK with you, Rudi? > > I do like the idea of using data in another part of the DNS forest to > hold prefix-dial strings is useful for prefix or "on-demand" carrier > selection, so I think that it's something I'd be loath to discourage. > (i.e. not lower than MAY, please :) > > In terms of standardising the data format, this could WELL be another > tel: URI, using a local_phone_subscriber number with a global phone > context tag to indicate where the prefix can be used. > Thus I think that the following works: . > > The information could be held in a NAPTR record under the Operator's > ".at." domain - that seems a useful way of storing it, and in a useful > place. If anyone has alternative proposals, please holler. > > I *do* have a question on whether or not this NAPTR or URI needs a tag > to indicate that it's not a dialable number on its own. Any thoughts > on this will be gratefully received. > > all the best, > Lawrence > > > -- > lwc@roke.co.uk: +44 1794 833666::: > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 12:36:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07201 for ; Thu, 28 Feb 2002 12:36:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17537 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 12:36:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16542; Thu, 28 Feb 2002 12:26:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16512 for ; Thu, 28 Feb 2002 12:26:13 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06382 for ; Thu, 28 Feb 2002 12:26:08 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.224]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g1SHQ7tQ002823; Thu, 28 Feb 2002 18:26:08 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Feb 2002 18:02:44 +0100 Message-ID: From: "Stastny, Richard" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , Brandner Rudolf , enum@ietf.org Cc: Conroy Lawrence Subject: RE: [Enum] Common Issues with ENUM and enumservices Date: Thu, 28 Feb 2002 18:02:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA16513 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Hi folks, reading the officiall issue of ID RFC2916bis very carefully, I recognized that the authors added the part on the blank flag, which indicates a non-terminal rule So we have now three and a half ways for redirection: CNAME no flag tel with and without flag (if tel with flag U is considered terminal) There are of course some subtle differences (please enlighten me if something is wrong or missing) 1. CNAME allows no other NAPTRs and therefore redirects the whole zone. 2. no flag redirects only the one NAPTR record, if it already decided to use that NAPTR record, so it redirects only one service? 3. Tel with U flag terminates, that is I SHALL use this number to make a phone call 4. Tel without flag is like 2., it redirects the tel service (hopefully not in a monday loop, Lawrence) Is this correct? As already stated, I am not an expert with ERE, what happens with the AUS in all this cases? regards Richard Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com > -----Original Message----- > From: Patrik F�ltstr�m [mailto:paf@cisco.com] > Sent: Thursday, February 28, 2002 5:29 PM > To: Brandner Rudolf; enum@ietf.org > Cc: Conroy Lawrence > Subject: Re: [Enum] Common Issues with ENUM and enumservices > > > --On 2002-02-27 19.57 +0100 Brandner Rudolf > wrote: > > > There seems to be a missing element to the documents as proposed in > > 2916bis. Maybe there's room for another document, giving > general issues > > that are common either to the use of existin DNS features or to all > > enumservices. This SHOULD NOT discuss which tree within the > DNS forest > > should hold ENUM NAPTRs. > > I have some comments / questions...because I don't really get > it. Sorry. > > > Single question to the list - should there be another > document tied with > > these others that describes these items? > > Maybe. > > > Background: > > While writing the tel enumservice draft, we realized, that > there were > > some possible uses of DNS that were related. For example, a > CNAME could > > be used to represent a forwarding service. However, some > issues with the > > use of a CNAME RR within e164.arpa are not really tied to the tel > > enumservice at all. Instead, they are common to all > enumservices (and > > potentially general to all uses of NAPTRs). > > If you have a CNAME with one owner, you can not at the same > time have NAPTR > with the same owner. Instead, you can have a NAPTR which > reference to a > different owner where the final NAPTR resides, by having an empty flag > field. > > So, already today, you _can_ have a pointer from one record > in one zone to > a record in a different zone. Different zones, different > administrative > entities. > > Is your point the need for different entities for different > NAPTR records? > > > Also, while looking at the overall service that could be > provided, we > > considered data to be held in other trees of the DNS > (please note - this > > is NOT intended to trigger another "use my TLD" blast of hot air, my > > air-conditioning bill for reading this list has already > exceeded this > > year's budget). > > :-) > > > For example, a NAPTR (*not* using the ENUM service) could > store useful > > data, which could also be used by a client of ENUM when > dealing with the > > returned enumservice. An example we gave were for storage of service > > provider contact info (e.g. phone number) or prefix dial string. > > Possible with specific enumservices from my point of view. > Maybe them will > also use tel: URI schemes? > > > In > > addition, we considered how to report a broken listing and > CLI my not > > give an immediately useful identifier. > > Ok. > > > Finally, we wondered about priority/preference and order. A > suggestion > > was made, that a particular enumservice should have precedence over > > another, or there should be only one NAPTR. What is the resolution > > process if more than one enumservice document makes the > same stricture? > > The priority/preference must be calculated over all NAPTR > records with the > same owner. I.e. it is calculated as part of the DNS > resolution, and not > the NAPTR resolution. > > > All of these issues are not unique to the tel enumservice and they > > haven't to do with the base procedures of 2916bis or the proceures > > described in the DDDS documents, hence the question. > > I have not described the priority/preference issues, and I have not > described the (in-)ability of using CNAME, empty flag fields for NAPTR > records etc because those are DNS issues, and not ENUM issues. > > Not saying I don't want to write about them. Just as an explanation. > > paf > > > _______________________________________________ > 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 daemon@optimus.ietf.org Thu Feb 28 13:36:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11293 for ; Thu, 28 Feb 2002 13:36:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20740 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 13:36:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19869; Thu, 28 Feb 2002 13:27:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19838 for ; Thu, 28 Feb 2002 13:27:14 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10766 for ; Thu, 28 Feb 2002 13:27:10 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.224]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g1SIR5tQ007758; Thu, 28 Feb 2002 19:27:06 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Feb 2002 19:09:49 +0100 Message-ID: From: "Stastny, Richard" To: "'Lawrence Conroy'" , "Stastny, Richard" Cc: enum@ietf.org, Rudi Date: Thu, 28 Feb 2002 19:09:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: Richard Stasny's review of brandner-enum-tel Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Lawrence wrote > * The comments on ss4.1 is well taken. > As the (public) ENUM entries SHOULD be a full > "global_phone_subscriber" > number (i.e. an E.164 number) there is no need to have a > phone-context. > > Adding a sentence to spell out SHOULD NOT use > ";phone-context=" in case > of a "tel:" URI with a full E.164 number is fine. Will add. > > BTW, I am a little concerned that we exclude 1-800 numbers that are > only "dialable" from a given region, if we make the E.164 > number a MUST > which is why it's a SHOULD (and use of phone-context will be a SHOULD > NOT). I'm not sure if this is a problem, so would appreciate anyone's > comments on this. > Mmm.., I like the idea of having local or regional 800 and other applications like this in and was thinking about this the whole time. In the brandner draft the phone-context means the context if which the tel: should be used, that is, you MAY use the tel: if you are in the same context (or you may upgrade it to a full number by adding the context?). The problem here is, that it may be not easy to negotiate the context with your service provider or the context of gateway of the service provider, especially if you use more than one or if you use in addition the TSP parameter (now my brain is starting to get overheated). The second usage of the phone-context (or another context) may be to match this with the context of your location (a DHCP parameter?), or what you define to be your location ;-) Maybe there is an approach like this for (public) ENUM: First, we have a zone in ENUM for +80012341234 or +18001231234 or +43800123456 for +80012341234, we enter NAPTR records with the same preference and tel:+49123456;phone-context=+43 -- phone number of call center from Austria tel:+49123456;phone-context=+49 -- same phone number from Germany tel:+353123456;phone-context=+44 -- call center in Ireland from UK tel:+353123456 -- default, if context is unknown for +18001231234, e.g.: tel:+12151231234;phone-context=+1215 tel:+12151231234;phone-context=+1412 -- and also from Pittsburgh etc. So we may have 2 phone contexts: caller-location-context and presented-number-context There is only one problem with this: most national numbering plans are loosing the locality now, and it work only for geographic numbers. Maybe the caller-location context should be given by other codes (specification required). The other problem is, we start to make DNS an IN SCP, especially if somebody comes up now with the idea to add a valid from-to time and date ;-) best regards and good night (for my local context its already to late to work anyway) Richard PS: Will it be possible to create vanity domains under e.164.arpa, like f.l.o.w.e.r.s.0.0.8.1.e164.arpa? Just joking, this has to be built in the client. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 14:01:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13037 for ; Thu, 28 Feb 2002 14:01:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22473 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 14:01:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21538; Thu, 28 Feb 2002 13:53:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21509 for ; Thu, 28 Feb 2002 13:53:07 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12344 for ; Thu, 28 Feb 2002 13:53:04 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1SIpS802588; Thu, 28 Feb 2002 13:51:28 -0500 Message-Id: <5.1.0.14.2.20020228134839.040ceb80@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Feb 2002 13:51:03 -0500 To: "Stastny, Richard" , "'Lawrence Conroy'" , "Stastny, Richard" From: Richard Shockey Subject: Re: [Enum] RE: Richard Stasny's review of brandner-enum-tel Cc: enum@ietf.org, Rudi In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 07:09 PM 2/28/2002 +0100, Stastny, Richard wrote: >Maybe there is an approach like this for (public) ENUM: > >First, we have a zone in ENUM for +80012341234 or +18001231234 or >+43800123456 > >for +80012341234, we enter NAPTR records with the same preference and > >tel:+49123456;phone-context=+43 -- phone number of call center from Austria >tel:+49123456;phone-context=+49 -- same phone number from Germany >tel:+353123456;phone-context=+44 -- call center in Ireland from UK >tel:+353123456 -- default, if context is unknown > >for +18001231234, e.g.: >tel:+12151231234;phone-context=+1215 >tel:+12151231234;phone-context=+1412 -- and also from Pittsburgh >etc. > >So we may have 2 phone contexts: >caller-location-context and >presented-number-context > >There is only one problem with this: most national numbering plans are >loosing the locality now, and it work only for geographic numbers. Maybe the >caller-location context should be given by other codes (specification >required). The other problem is, we start to make DNS an IN SCP, especially >if somebody comes up now with the idea to add a valid from-to time and date >;-) Well you might be interested to know there is some thinking going on along these lines: Title : The Calling Party's Category tel URL Parameter Author(s) : J. Peterson Filename : draft-peterson-tel-cpc-00.txt Pages : 9 Date : 27-Feb-02 This document specifies a new parameter for the tel URL [1] that represents the Calling Party's Category, a parameter used in SS7 ISUP [2] signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peterson-tel-cpc-00.txt >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 14:51:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15909 for ; Thu, 28 Feb 2002 14:51:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25181 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 14:51:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24753; Thu, 28 Feb 2002 14:41:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24720 for ; Thu, 28 Feb 2002 14:40:59 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15358 for ; Thu, 28 Feb 2002 14:40:54 -0500 (EST) Received: from [193.118.192.40] ([193.118.192.40] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062973; Thu, 28 Feb 2002 19:40:56 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Thu, 28 Feb 2002 19:40:52 +0000 To: rich.shockey@NeuStar.com From: Lawrence Conroy Subject: Re: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Cc: enum@ietf.org, Rudi Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Richard Sh, Folks, Following on from Rudi's comments... RS said: speed of DNS is OK RB said: Yup. Others have said this, though LwC sez: I think we're wildly agreeing. However, check out the earlier thread that drifted off into a rathole; notably Christian's (technical!) comments. RS said: I do respectfully disagree. RB said: I do respectfully disagree with your disagreement. LwC sez: The point Rudi was making was that the SRS redirection doesn't help with latency. I don't see how this is wrong. You (and I) may well trade off call setup time (strictly, post-dial delay) against privacy. Fine. However, SRS doesn't ->help<- latency, particularly if it involves authentication and/or encryption. RS said: (on the the 'tel' enumservice draft) You propose a call forwarding service using "tel:" URLs - but why? Why would I (an end user) want to expose this info in the DNS rather than use a SIP or PSTN service where my prefs are hidden and the service is more suited to real-time dynamic updates? RB said: I pass the buck :) LwC sez: Why?.....Well..Here goes:: 'tel' redirection is there if you want it, for whatever reason you choose. First, the end user CAN use tel: redirects. They are unlikely to be able to use CNAME redirects, as this will require admin access to the parent zone; I suspect that the registry owner (and/or the Operator with the 10K number block allocation) will be unhappy with Joe Public diddling with this. I expect use for Operator admin purposes, BY Operator admin people (for example by O&M to insert a long term patch from one number to another). However, "tel:" redirects I (as joe public) CAN use. Sure, I could just as easily use my PSTN service provider's offering (assuming that it's someone else's money - YMMV but in the U.K. this has a non-trivial cost). Equally, I can use the new SIP service from your friendly Sunshine ISP/Telco. BUT... What if I'm actually calling from a hybrid phone (not an all singing all dancing IP phone, or even a Pingtel one :)? Maybe it's a GSM/GPRS handy where I may be able to get a 28.8 Kbps link, but that's not really enough for the SIP provider, as they don't handle EFR or AMR codecs, at least not when I'm trying to break out to the PSTN in the U.S. of A.; thus this is, in effect, a hybrid too - I can look up numbers over the IP connection, but then I'll drop back and use the PLMN to call out as I can't get the bandwidth for the required G.711 codec. In summary, with a "tel:" it's possible that I can go from what is, in effect, the GSTN to a termination that is also in the GSTN without (i) going through the PSTN Operator's idea of a reasonable cost service or (ii) going into a SIP/RTP provider and than back out again. Now, for the inappropriateness of DNS due to cache latencies. I want a system that can provide near real time updates. That's not what the majority of the users are going to get (or pressure on calling plan costs is merely a figment of my over-active imagination). It's a premium service, and there may well be a cost associated with it. I believe that there is more than one market, with more than one set of requirements - it's not even just a case of cheap versus flexible, but some points in between. What you're focusing on is one mechanism that can provide a super service, but what I'm looking at is another (basic) mechanism that is NOT going to be hard to implement but that is going to provide some useful features. We should have both. Yes, listing using DNS does expose information to anyone who wants it - even if you don't want them to know this. I contend that, for many folk, this is not too tragic. The percentage of people who bother to fire up CLIR is not too high; that's a originating case, but I guess the terminating case is not too different. There are times where having this information may actually save me a call (if I'm intending to originate). For example, at work, as soon as my phone shows that the call has been bounced off to Voice Mail, I usually clear (Sorry, I'm a Luddite). The ENUM equivalent is to find this from DNS before I hit the "go" button. Call Saver, anyone? If I want to give information ONLY for people on my ACL, then I can use SIP (or a web site, using HTTPS, or whatever). That's fine. However, I can only hide the actual destination number if I go via the PSTN, *or* I use the 3GPP whacko-extensions to SIP. Using a SRS only supports the ACL-checking, not normally a full destination-hiding scenario. Frankly, the concept of privacy would be nice if I could use it but I just don't have enough money (and/or the speech latency) for it; I'm sure that if someone else were to pay for my calls I'd be happy, but for now I'll settle for cheap. This does not exclude the whizzy secure service that can be provided otherwise - I *want* there to be such a service, I just don't want everyone to have to pay for it. Best Regards, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 15:15:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17212 for ; Thu, 28 Feb 2002 15:15:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27019 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 15:15:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26209; Thu, 28 Feb 2002 15:05:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26175 for ; Thu, 28 Feb 2002 15:05:20 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16641 for ; Thu, 28 Feb 2002 15:05:15 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id VAA25726; Thu, 28 Feb 2002 21:05:07 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id VAA22542; Thu, 28 Feb 2002 21:04:59 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id <1J4RB7W7>; Thu, 28 Feb 2002 21:05:12 +0100 Message-ID: From: Brandner Rudolf To: "'Zmolek, Andrew (Andrew)'" , Richard Shockey , enum@ietf.org Cc: Conroy Lawrence Subject: AW: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Date: Thu, 28 Feb 2002 21:04:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA26176 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Comments inline and deleted Richard Shockey's comments as I answered (partially) to that. > -----Urspr�ngliche Nachricht----- > Von: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com] > Gesendet: Mittwoch, 27. Februar 2002 23:11 > An: Richard Shockey; Brandner Rudolf; enum@ietf.org > Cc: Conroy Lawrence > Betreff: RE: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt > > > At long last, some discussion! If I understand you correctly, Yes, it seems to me, that we are making progress here, even if we do not agree on all issues (yet). > these seem > to be your concerns: > > 1. DNS resolution latency is already a concern, why make it worse by > adding a pointer? > 2. Why add another layer of indirection when service resolution could > take place directly? > 3. Since codec capabilities are embedded in service field tags, why > worry about negotiation? > 4. Isn't it enough that SIP offers such a service resolution > service for > "presence" > 5. Is a specific URI scheme or architecture being proposed here? > 6. Why suggest that the ENUM service provider and service resolution > service provider might be the same? > > Here's my take on the answers to each: > > 1. DNS resolution latency obviously must be kept within the range of > human tolerance when sessions need to be established. But if there's > truly a latency problem with adding service resolution > pointers to ENUM > in general, then SIP in particular would be unusable with ENUM. This > topic of resolution latency is an interesting rathole, I suppose, but > ultimately falls in the category of universal challenges to ENUM in > general. > You are absolutely right. In the case of pres: the resolution points off ENUM and we are done. Er, not quite. Actually I do not know what protocol and application is used. That makes it hard to further elaborate on this topic as it would be a discussion on assumtions. > 2. Adding a layer of indirection should only be done when the > alternatives are more ugly, and I believe service resolution services > are just such a case. Here's why: > > - The mapping of E.164 addresses to devices (or systems behind the > devices) is not one-to-one today and is increasingly one-to-many for a > given E.164 address (and many-to-many overall) > - Not all systems and devices have or will have the same > capabilities, > even indirectly > - Associations between devices and E.164 numbers can change more > rapidly and frequently than the cache-friendly DNS system can support > (consider the case of call forwarding today mapped against > the large TTL > of a DNS reply) > > Strong association of detailed service capabilities with E.164 numbers > via ENUM would either: > A. Reduce accuracy of resulting information by giving > information only > for ENUM-registered endpoints when one or more non-registered > endpoints > may ultimately terminate a call to a given E.164 number. > B. Somehow forbid non-registered endpoints from terminating a call > initiated through ENUM (bye-bye call forwarding!) > C. Force ENUM service providers to act as a public > "presence" service, > updating service-tags and capabilities in real-time. > I do not get A. B. C. Would you please clarify what you mean by 'ENUM-registered' or non-registered. > Note that none of these options is desirable, and none > tackles issues in > the sphere of privacy, public exposure of information, hacking via > service profiling, etc. So it is my assertion that for many cases a > "service resolution" level of indirection is justified here. I am > careful to note, however, that in some specific cases, no level of > indirection is needed or desired--ENUM clearly has value in > both cases. > privacy, public exposure ...... Having a "service resolution" might not help much, too. If I ask you a question, there are 2 basic answers: you just refuse to talk to me, or you talk to me. Agreed, with ENUM, I might reveal more information (which, to some extend is outlined in our draft) than with a service resolution. If the "service resolution" finally answeres my request, I think, that service profiling can be done anyway. I *think*, because I actually do not know what that "service resolution" is going to be in terms of authentication (which would be necessary if you have ACLs), integrity and privacy. > 3. Just because you can embed codec capabilities in service > tags doesn't > mean it's a good idea. In addition to the dynamic endpoints and > capabilities problem I discuss in #2 above, there's the issue > of service > tag multiplication which gets even uglier when transcoding tags are > used. If the resolution latency issue you raise is important to you, > then I would think you would want to avoid the possibility of > forcing a > TCP session setup and teardown just because your service tag > list won't > fit in a UDP packet anymore. Does anything more really need to be said > here? > I am with you here, I do not like long transcoding tags, either. Regarding TCP session setup, well, the information *has* to be transmitted to the client one way or the other. If it is too long for UDP, it has to go via TCP, one way or the other. There is no cost savings here. I am just worried, that the "service resolution" protocol might add *much* extra cost through authentication, signing the content and encryption. How much this might be I do not know, as I do not know what you have in mind as a "service resolution" protocol and application. BTW: With current specs, you can have about 7 NAPTRs in a packet, if you double the size of the NAPTRs, it'll get you 3 to 4 in a packet. > 4. Within the world that SIP encompasses (which is admittedly > a lot), I > have to say that SIP does a good job of acting as a service resolution > pointer. I am very supportive of SIP as such, but that doesn't mean I > believe that SIP-based presence is ready or willing to provide more > general, signaling-protocol agnostic presence services. Just > because SIP > offers one approach to presence doesn't mean that it is useful to > exclude others, even if they are not yet mature or fully formed. > Frankly, many other presence services already exist within limited > realms and all of them would benefit from an open protocol for > interchange of that information. From the ENUM point of view, I would > assert that we shouldn't be in the business of picking winners for > presence services. Yet we should still make the bar reasonably high > before assigning a service tag to such a service. > Agreed, we should not pick winners. BTW: it would be good to know, who are the runners? > 5. If it wasn't clear in the draft, let me make it perfectly > clear here: > I am not proposing a service tag or specific service. This is > intentional, and although I did include some examples, they are not > intended to form the basis of any proposal for a tag or a service. So > what am I proposing? Mainly an examination of some critical issues we > need to take into account as we consider how to deal with > service tags, > codec negotiation, "presence" services, and the like. I would submit > that having a notion of "service resolution" services within the ENUM > worldview allows us to make better decisions about what is > allowable in > service field tags and what belongs elsewhere. To be blunt, the > availability of "service resolution" services, SIP-based or not, > eliminates much of the previous justification for detailed and complex > service field tags and may help us move on to more important topics. > OK. Agreed > 6. Suggesting that the ENUM service provider might also > provide presence > services was my way of demonstrating that there's something > in this for > the ENUM service provider as well. But it was *JUST A SUGGESTION*, > nothing more. For those that missed this in the draft, let me > reinforce > that there need not be any connection at all between the two > beyond the > service field tag and URI to point there. In fact, many large > enterprises will probably do a presence service themselves, > just as they > do with their DNS services. Or they might outsource, just as they do > with their DNS services. > I agree. I'd be happy to read this in the next version of your draft. > In summary, service resolution latency is important, there's a good > reason for service resolution services, SIP's a reasonable (if not > complete) example of such a service, and indeed there is a difference > between providers of ENUM and service resolution services. > Thanks again > for your note. I'm looking forward to more conversation on > these issues, > as I think they get to the heart of the ENUM value proposition for all > parties. > Perfect summary. I violently agree. > --Andy Zmolek > Technology & Standards Engineer > CTO Standards > Avaya Inc. > > zmolek@avaya.com > +1 720 444 4001 > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 15:17:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17376 for ; Thu, 28 Feb 2002 15:17:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27126 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 15:17:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26467; Thu, 28 Feb 2002 15:07:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26364 for ; Thu, 28 Feb 2002 15:07:45 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16755 for ; Thu, 28 Feb 2002 15:07:39 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id VAA07053; Thu, 28 Feb 2002 21:07:39 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id VAA22611; Thu, 28 Feb 2002 21:07:29 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id <1J4RB7X3>; Thu, 28 Feb 2002 21:07:42 +0100 Message-ID: From: Brandner Rudolf To: =?ISO-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: Conroy Lawrence , enum@ietf.org Subject: AW: [Enum] Common Issues with ENUM and enumservices Date: Thu, 28 Feb 2002 21:07:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA26365 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Comments inline. > -----Urspr�ngliche Nachricht----- > Von: Patrik F�ltstr�m [mailto:paf@cisco.com] > Gesendet: Donnerstag, 28. Februar 2002 17:29 > An: Brandner Rudolf; enum@ietf.org > Cc: Conroy Lawrence > Betreff: Re: [Enum] Common Issues with ENUM and enumservices > > > --On 2002-02-27 19.57 +0100 Brandner Rudolf > wrote: > > > There seems to be a missing element to the documents as proposed in > > 2916bis. Maybe there's room for another document, giving > general issues > > that are common either to the use of existin DNS features or to all > > enumservices. This SHOULD NOT discuss which tree within the > DNS forest > > should hold ENUM NAPTRs. > > I have some comments / questions...because I don't really get > it. Sorry. > > > Single question to the list - should there be another > document tied with > > these others that describes these items? > > Maybe. > > > Background: > > While writing the tel enumservice draft, we realized, that > there were > > some possible uses of DNS that were related. For example, a > CNAME could > > be used to represent a forwarding service. However, some > issues with the > > use of a CNAME RR within e164.arpa are not really tied to the tel > > enumservice at all. Instead, they are common to all > enumservices (and > > potentially general to all uses of NAPTRs). > > If you have a CNAME with one owner, you can not at the same > time have NAPTR > with the same owner. Instead, you can have a NAPTR which > reference to a > different owner where the final NAPTR resides, by having an empty flag > field. > > So, already today, you _can_ have a pointer from one record > in one zone to > a record in a different zone. Different zones, different > administrative > entities. > > Is your point the need for different entities for different > NAPTR records? > Not quite, we know that a CNAME is a complete redirection. This is transparent to DDDS, so there are some impacts on RegExp matching. > > Also, while looking at the overall service that could be > provided, we > > considered data to be held in other trees of the DNS > (please note - this > > is NOT intended to trigger another "use my TLD" blast of hot air, my > > air-conditioning bill for reading this list has already > exceeded this > > year's budget). > > :-) > > > For example, a NAPTR (*not* using the ENUM service) could > store useful > > data, which could also be used by a client of ENUM when > dealing with the > > returned enumservice. An example we gave were for storage of service > > provider contact info (e.g. phone number) or prefix dial string. > > Possible with specific enumservices from my point of view. > Maybe them will > also use tel: URI schemes? > Interesting, maybe a specific enumservice for prefix dial string. Good idea. > > In > > addition, we considered how to report a broken listing and > CLI my not > > give an immediately useful identifier. > > Ok. > > > Finally, we wondered about priority/preference and order. A > suggestion > > was made, that a particular enumservice should have precedence over > > another, or there should be only one NAPTR. What is the resolution > > process if more than one enumservice document makes the > same stricture? > > The priority/preference must be calculated over all NAPTR > records with the > same owner. I.e. it is calculated as part of the DNS > resolution, and not > the NAPTR resolution. > I see, you mean in the same zone? > > All of these issues are not unique to the tel enumservice and they > > haven't to do with the base procedures of 2916bis or the proceures > > described in the DDDS documents, hence the question. > > I have not described the priority/preference issues, and I have not > described the (in-)ability of using CNAME, empty flag fields for NAPTR > records etc because those are DNS issues, and not ENUM issues. > Yes, that is strictly true, however, the 'ENUM environment' includes those and they are admin issues. > Not saying I don't want to write about them. Just as an explanation. > So I look forward to reading this ;^) > paf > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 15:31:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18233 for ; Thu, 28 Feb 2002 15:31:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA28443 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 15:31:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27364; Thu, 28 Feb 2002 15:21:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27333 for ; Thu, 28 Feb 2002 15:21:27 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17579 for ; Thu, 28 Feb 2002 15:21:22 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1SKKs806100; Thu, 28 Feb 2002 15:20:54 -0500 Message-Id: <5.1.0.14.2.20020228151056.022bd518@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Feb 2002 15:23:16 -0500 To: Lawrence Conroy From: Richard Shockey Subject: Re: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Cc: enum@ietf.org, Rudi In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 07:40 PM 2/28/2002 +0000, Lawrence Conroy wrote: >Hi Richard Sh, Folks, > >Yes, listing using DNS does expose information to anyone who wants it - >even if you don't want them to know this. I contend that, for many folk, >this is not too tragic. The percentage of people who bother to fire up >CLIR is not too high; that's a originating case, but I guess the >terminating case is not too different. > >There are times where having this information may actually save me a call >(if I'm intending to originate). For example, at work, as soon as my phone >shows that the call has been bounced off to Voice Mail, I usually clear >(Sorry, I'm a Luddite). The ENUM equivalent is to find this from DNS >before I hit the "go" button. Call Saver, anyone? > >If I want to give information ONLY for people on my ACL, then I can use >SIP (or a web site, using HTTPS, or whatever). That's fine. However, I can >only hide the actual destination number if I go via the PSTN, *or* I use >the 3GPP whacko-extensions to SIP. Using a SRS only supports the >ACL-checking, not normally a full destination-hiding scenario. > >Frankly, the concept of privacy would be nice if I could use it but I just >don't have enough money (and/or the speech latency) for it; I'm sure that >if someone else were to pay for my calls I'd be happy, but for now I'll >settle for cheap. This does not exclude the whizzy secure service that can >be provided otherwise - I *want* there to be such a >service, I just don't want everyone to have to pay for it. Ok ... correct me if I'm wrong. I'm trying to simplify the argument here ..so the basic technical and business case for a TEL URL based redirection service is that you can screw some poor unsuspecting incumbent Telco out of a fat margin C7 based Call Forwarding product. Right ? OK ... I'm sold. I'll buy that. Why did'nt you say so in the first place? :-) Privacy issue is a non issue since this is Opt-In for the perceived benefit(s). >lwc@roke.co.uk: +44 1794 833666::: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 16:47:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21430 for ; Thu, 28 Feb 2002 16:47:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02927 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 16:47:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02421; Thu, 28 Feb 2002 16:38:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02393 for ; Thu, 28 Feb 2002 16:38:19 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21113 for ; Thu, 28 Feb 2002 16:38:13 -0500 (EST) Received: from [0.0.0.0] (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA27876; Thu, 28 Feb 2002 22:37:40 +0100 (MET) Date: Thu, 28 Feb 2002 16:31:42 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Brandner Rudolf cc: Conroy Lawrence , enum@ietf.org Subject: Re: AW: [Enum] Common Issues with ENUM and enumservices Message-ID: <29660208.1014913902@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-28 21.07 +0100 Brandner Rudolf wrote: >> Is your point the need for different entities for different >> NAPTR records? > > Not quite, we know that a CNAME is a complete redirection. This is > transparent to DDDS, so there are some impacts on RegExp matching. What impacts? Can you give an example? >> The priority/preference must be calculated over all NAPTR >> records with the >> same owner. I.e. it is calculated as part of the DNS >> resolution, and not >> the NAPTR resolution. > > I see, you mean in the same zone? The priority/preference is calculated over all NAPTR with the same owner. If two sets of NAPTR are in the same zone, but with different owners, the two sets are used separated from each other. Example: If I have a.example.com and two NAPTR for that owner, the priority and preference is calculated over both records, regardless of the service or flag fields. If also have b.example.com in the same zone, that is not included in the calculation. I _think_ you with "zone" mean same "owner", i.e. same domain name? >> Not saying I don't want to write about them. Just as an explanation. > > So I look forward to reading this ;^) Hmmm....there are nice books about how DNS works ;-) paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Feb 28 16:50:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21562 for ; Thu, 28 Feb 2002 16:50:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03067 for enum-archive@odin.ietf.org; Thu, 28 Feb 2002 16:50:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02691; Thu, 28 Feb 2002 16:42:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02663 for ; Thu, 28 Feb 2002 16:42:07 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21308 for ; Thu, 28 Feb 2002 16:42:03 -0500 (EST) Received: from [0.0.0.0] (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA27888; Thu, 28 Feb 2002 22:37:46 +0100 (MET) Date: Thu, 28 Feb 2002 16:37:13 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Stastny, Richard" , Brandner Rudolf , enum@ietf.org cc: Conroy Lawrence Subject: RE: [Enum] Common Issues with ENUM and enumservices Message-ID: <29680034.1014914233@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-02-28 18.02 +0100 "Stastny, Richard" wrote: > reading the officiall issue of ID RFC2916bis very carefully, I recognized > that the authors added the part on the blank flag, which indicates a > non-terminal rule Nice, isn't it? :-) > So we have now three and a half ways for redirection: > CNAME > no flag > tel with and without flag (if tel with flag U is considered terminal) tel without a flag? You talk about no flag, but with E2U+TEL as the service? > There are of course some subtle differences (please enlighten me if > something is wrong or missing) > > 1. CNAME allows no other NAPTRs and therefore redirects the whole zone. Redirects the domain name. You imply that the zone has the same owner as the record, and that is not good. I would say impossible, as a zone have always by definition an SOA record. > 2. no flag redirects only the one NAPTR record, if it already decided to > use that NAPTR record, so it redirects only one service? Only that NAPTR. Other NAPTR might have the same service. > 3. Tel with U flag terminates, that is I SHALL use this number to make a > phone call U is terminal. Correct. > 4. Tel without flag is like 2., it redirects the tel service (hopefully > not in a monday loop, Lawrence) Yes. > Is this correct? Yes, modulo that the terminology issues about redirection with CNAME. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum