From clive@demon.net Thu, 01 Jul 2004 09:28:14 -0400 From: "Clive D.W. Feather" Date: Thu, 01 Jul 2004 09:28:14 -0400 To: Stastny Richard Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1624437C2@oefeg-s02.oefeg.loc> Message-ID: <20040701095329.GK34093@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: RO Stastny Richard said: >> Richard, *please* fix your mail software. It is very annoying to get >> needless base-64 encodings of UTF-8 that's actually just ASCII text. >> Even more irritating is finding a mail tool to translate that encoding >> back to ASCII so that your words of wisdom can be read. Grrr! > On the other hand, I consider UTF-8 as a valid standard and seemingly > most normal mail SW is able to understand it. Even the IETF archive > has been updated to decipher it. Your mail is arriving here in quoted-printable, not base64. I don't know why he's complaining. And both Mutt and Turnpike seem to be able to handle your emails with no difficulty whatsoever; in fact, I had to make an effort to find out what all the fuss was about. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From clive@demon.net Thu, 01 Jul 2004 09:31:54 -0400 From: "Clive D.W. Feather" Date: Thu, 01 Jul 2004 09:31:54 -0400 To: enum at ietf.org Subject: [Enum] Libel from Jim Reid Message-ID: <20040701100057.GL34093@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: RO I have just received the message: ----- The following addresses had permanent fatal errors ----- (reason: 550 5.0.0 Mail from spammers is refused - get lost.) ----- Transcript of session follows ----- ... while talking to gromit.rfc1035.com.: >>> MAIL From: <<< 550 5.0.0 Mail from spammers is refused - get lost. 554 5.0.0 ... Service unavailable I am not and never have been a spammer, and I consider this libel unacceptable. I am a subscriber to this list in good standing, and see no reason why I should be treated like this. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Thu, 01 Jul 2004 09:34:33 -0400 From: "Conroy, Lawrence (SMTP)" Date: Thu, 01 Jul 2004 09:34:33 -0400 To: Richard Shockey Subject: Re: [Enum] Fwd: [Sipping] RFC 3824 on Using E.164 numbers with the Session Initiation Protocol (SIP) In-Reply-To: <6.1.0.6.2.20040629193930.03854ec0@joy.songbird.com> Message-ID: <6FC13A22-CB46-11D8-A303-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Richard, folks, I quote from RFC3824 of June 2004: Note that the ENUM specification has undergone a revision shortly before the publication of this document, driven by the update of the NAPTR system described in RFC 2915 [12] to the Dynamic Delegation Discovery System (DDDS) family of specifications (including RFC 3403). This document therefore provides some guidance for handling records designed for the original RFC 2916 [16]. Super. We try to convince people to use 340x/3761, and this RFC talks only about the old/obsolete stuff. It's not like RFC3761 was issued in great haste or had late changes to the syntax or concept or anything (nor did RFC3764). As for the update from 2915 to 340x, that was hardly recent. Coordination must be a great thing. all the best, Lawrence On 30 Jun 2004, at 00:39, Richard Shockey wrote: To: ietf-announce at ietf.org From: rfc-editor at rfc-editor.org Date: Tue, 29 Jun 2004 16:24:46 -0700 Cc: sipping at ietf.org, rfc-editor at rfc-editor.org Subject: [Sipping] RFC 3824 on Using E.164 numbers with the Session Initiation Protocol (SIP) A new Request for Comments is now available in online RFC libraries. RFC 3824 Title: Using E.164 numbers with the Session Initiation Protocol (SIP) Author(s): J. Peterson, H. Liu, J. Yu, B. Campbell Status: Informational Date: June 2004 There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Thu, 01 Jul 2004 11:40:47 -0400 From: Mike Hammer Date: Thu, 01 Jul 2004 11:40:47 -0400 To: Jeff Williams Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <17086.1088586316@gromit.rfc1035.com> Message-ID: <4.3.2.7.2.20040701103032.00b02c90@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 08:11 PM 6/30/2004 -0700, Jeff Williams wrote: of their personal and private data such as their name, ENUM number, address, and direct contact phone number. Jeff, While other elements might be private data, the E.164 number is not. The E.164 number MUST be visible to enable universal routing of calls to at least some node that can reach the terminal assigned that E.164 number. The privacy issue is about what OTHER data gets associated with the E.164 number, that is SPECIFIC to an INDIVIDUAL. Please get this straight in your mind. Mike _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 01 Jul 2004 13:12:14 -0400 From: "Stastny Richard" Date: Thu, 01 Jul 2004 13:12:14 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] Fwd: [Sipping] RFC 3824 on Using E.164 numbers with theSession Initiation Protocol (SIP) Message-ID: <06CF906FE3998C4E944213062009F1624437C7@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Be careful: Quod licet Jovi, non licet bovi Richard -----UrsprÃngliche Nachricht----- Von: Conroy, Lawrence (SMTP) [mailto:lwc at roke.co.uk] Gesendet: Do 01.07.2004 12:07 An: Richard Shockey Cc: enum at ietf.org Betreff: Re: [Enum] Fwd: [Sipping] RFC 3824 on Using E.164 numbers with theSession Initiation Protocol (SIP) Hi Richard, folks, I quote from RFC3824 of June 2004: Note that the ENUM specification has undergone a revision shortly before the publication of this document, driven by the update of the NAPTR system described in RFC 2915 [12] to the Dynamic Delegation Discovery System (DDDS) family of specifications (including RFC 3403). This document therefore provides some guidance for handling records designed for the original RFC 2916 [16]. Super. We try to convince people to use 340x/3761, and this RFC talks only about the old/obsolete stuff. It's not like RFC3761 was issued in great haste or had late changes to the syntax or concept or anything (nor did RFC3764). As for the update from 2915 to 340x, that was hardly recent. Coordination must be a great thing. all the best, Lawrence On 30 Jun 2004, at 00:39, Richard Shockey wrote: > >> To: ietf-announce at ietf.org >> From: rfc-editor at rfc-editor.org >> Date: Tue, 29 Jun 2004 16:24:46 -0700 >> Cc: sipping at ietf.org, rfc-editor at rfc-editor.org >> Subject: [Sipping] RFC 3824 on Using E.164 numbers with the Session >> Initiation Protocol (SIP) >> >> A new Request for Comments is now available in online RFC libraries. >> >> RFC 3824 >> >> Title: Using E.164 numbers with the Session Initiation >> Protocol (SIP) >> Author(s): J. Peterson, H. Liu, J. Yu, B. Campbell >> Status: Informational >> Date: June 2004 >> >> There are a number of contexts in which telephone numbers are >> employed by Session Initiation Protocol (SIP) applications, many of >> which can be addressed by ENUM. Although SIP was one of the primary >> applications for which ENUM was created, there is nevertheless a need >> to define procedures for integrating ENUM with SIP >> implementations. This document illustrates how the two protocols >> might work in concert, and clarifies the authoring and processing of >> ENUM records for SIP applications. It also provides guidelines for >> instances in which ENUM, for whatever reason, cannot be used to >> resolve a telephone number. >> >> This document is a product of the Session Initiation Proposal >> Investigation Working Group of the IETF. >> >> This memo provides information for the Internet community. It does >> not specify an Internet standard of any kind. Distribution of this >> memo is unlimited. >> _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Thu, 01 Jul 2004 14:46:35 -0400 From: "Peter Williams" Date: Thu, 01 Jul 2004 14:46:35 -0400 To: enum at ietf.org Subject: [Enum] ldaps and E2U Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO One of the URI mappings mentioned in the ENUM RFC is from E.164 to an ldaps URI ; that is ldap (i.e. X.500 in drag) over SSL. Can anyone point me to a E2U client implementation that has an initial DNS lookup then cooperate with ldap(s) (preferably resolved using PRDMD-oriented ActiveDirectory implementation from Microsoft)? Alternatively , has anyone tried to put ENUM NAPTRs in the DNS schema of the active directory, so the directory can act as the responder for E2U queries- and thus benefit from well-understood management domain practices and knowledge distribution techniques for private domain access points? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ag@ag-projects.com Thu, 01 Jul 2004 16:06:13 -0400 From: Adrian Georgescu Date: Thu, 01 Jul 2004 16:06:13 -0400 To: "Peter Williams" Subject: Re: [Enum] ldaps and E2U In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO What would be the role of Active Directory with regards to ENUM? Could you detail on this? On Jul 1, 2004, at 8:29 PM, Peter Williams wrote: One of the URI mappings mentioned in the ENUM RFC is from E.164 to an ldaps URI ; that is ldap (i.e. X.500 in drag) over SSL. Can anyone point me to a E2U client implementation that has an initial DNS lookup then cooperate with ldap(s) (preferably resolved using PRDMD-oriented ActiveDirectory implementation from Microsoft)? Alternatively , has anyone tried to put ENUM NAPTRs in the DNS schema of the active directory, so the directory can act as the responder for E2U queries- and thus benefit from well-understood management domain practices and knowledge distribution techniques for private domain access points? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 01 Jul 2004 17:30:18 -0400 From: Richard Shockey Date: Thu, 01 Jul 2004 17:30:18 -0400 To: Adrian Georgescu Subject: Re: [Enum] ldaps and E2U In-Reply-To: Message-ID: <6.1.0.6.2.20040701170355.03b13ec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 03:49 PM 7/1/2004, Adrian Georgescu wrote: What would be the role of Active Directory with regards to ENUM? Could you detail on this? I would guess this is a TN to SIP AOR directory application for IP-PBX's. Use the corporate wide AD to manage SIP AOR's ..but you would have to get the IP-PBX's all to point to AD for resolution and the chances of that happening is about the same as getting them to add ENUM resolvers. Ask your Cisco rep when are they going to add a ENUM resolver into Call Manager ? ..oh sorry.. Alternatively , has anyone tried to put ENUM NAPTRs in the DNS schema of the active directory, so the directory can act as the responder for E2U queries- you would not put NAPTR in AD only the relevant SIP AOR. and thus benefit from well-understood management domain practices and knowledge distribution techniques for private domain access points? The concepts of "well-understood management practices" and Microsoft Active Directory strike me mutually exclusive. The answer to the question BTW is no ..it has not been done. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jon.peterson@neustar.biz Thu, 01 Jul 2004 18:24:19 -0400 From: "Peterson, Jon" Date: Thu, 01 Jul 2004 18:24:19 -0400 To: "'Conroy, Lawrence (SMTP)'" Subject: RE: [Enum] Fwd: [Sipping] RFC 3824 on Using E.164 numbers with th e Session Initiation Protocol (SIP) Message-ID: <7927C67249E4AD43BC05B539AF0D12980F7D7F@stntexch04.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Your characterization that this document "only talks about the old/obsolete stuff" is not borne out by the text. Material relating to backwards compatibility with RFC2916 is relegated to a single section; RFC3761 forms the basis of the meat of the document. You do however correctly point out that many of the temporal words in the document (like the "shortly" below) were timely when written but are grossly outdated today. Implementation and deployment experience will no doubt determine whether the backwards-compatibility text is necessary or superfluous - I would be happy to learn that it is never exercised. That the text could cause any real harm to deployments seems very counterintuitive to me. Finally, in deference to Mr. Stasny, I must insist that a call for backwards-compatibility is not solely the prerogative of Olympians. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc at roke.co.uk] > Sent: Thursday, July 01, 2004 3:07 AM > To: Richard Shockey > Cc: enum at ietf.org > Subject: Re: [Enum] Fwd: [Sipping] RFC 3824 on Using E.164 > numbers with > the Session Initiation Protocol (SIP) > > > Hi Richard, folks, > > I quote from RFC3824 of June 2004: > Note that the ENUM specification has undergone a revision shortly > before the publication of this document, driven by the > update of the > NAPTR system described in RFC 2915 [12] to the Dynamic Delegation > Discovery System (DDDS) family of specifications (including RFC > 3403). This document therefore provides some guidance > for handling > records designed for the original RFC 2916 [16]. > > Super. > We try to convince people to use 340x/3761, and this RFC talks only > about the old/obsolete stuff. > > It's not like RFC3761 was issued in great haste or had late > changes to > the syntax or concept or anything (nor did RFC3764). As for > the update > from 2915 to 340x, that was hardly recent. > > Coordination must be a great thing. > > all the best, > Lawrence > > On 30 Jun 2004, at 00:39, Richard Shockey wrote: > > > >> To: ietf-announce at ietf.org > >> From: rfc-editor at rfc-editor.org > >> Date: Tue, 29 Jun 2004 16:24:46 -0700 > >> Cc: sipping at ietf.org, rfc-editor at rfc-editor.org > >> Subject: [Sipping] RFC 3824 on Using E.164 numbers with the Session > >> Initiation Protocol (SIP) > >> > >> A new Request for Comments is now available in online RFC > libraries. > >> > >> RFC 3824 > >> > >> Title: Using E.164 numbers with the Session Initiation > >> Protocol (SIP) > >> Author(s): J. Peterson, H. Liu, J. Yu, B. Campbell > >> Status: Informational > >> Date: June 2004 > >> > >> There are a number of contexts in which telephone numbers are > >> employed by Session Initiation Protocol (SIP) applications, many of > >> which can be addressed by ENUM. Although SIP was one of > the primary > >> applications for which ENUM was created, there is > nevertheless a need > >> to define procedures for integrating ENUM with SIP > >> implementations. This document illustrates how the two protocols > >> might work in concert, and clarifies the authoring and > processing of > >> ENUM records for SIP applications. It also provides guidelines for > >> instances in which ENUM, for whatever reason, cannot be used to > >> resolve a telephone number. > >> > >> This document is a product of the Session Initiation Proposal > >> Investigation Working Group of the IETF. > >> > >> This memo provides information for the Internet community. It does > >> not specify an Internet standard of any kind. Distribution of this > >> memo is unlimited. > >> > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Thu, 01 Jul 2004 23:56:12 -0400 From: Jeff Williams Date: Thu, 01 Jul 2004 23:56:12 -0400 To: "Clive D.W. Feather" Subject: Re: [Enum] Libel from Jim Reid In-Reply-To: <20040701100057.GL34093@finch-staff-1.thus.net> Message-ID: <40E4F4DB.777D25DE@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Clive and all, I also recieved one of these. What's the deal or Real problem here? Clive D.W. Feather wrote: > I have just received the message: > > ----- The following addresses had permanent fatal errors ----- > > (reason: 550 5.0.0 Mail from spammers is refused - get lost.) > > ----- Transcript of session follows ----- > ... while talking to gromit.rfc1035.com.: > >>> MAIL From: > <<< 550 5.0.0 Mail from spammers is refused - get lost. > 554 5.0.0 ... Service unavailable > > I am not and never have been a spammer, and I consider this libel > unacceptable. I am a subscriber to this list in good standing, and see no > reason why I should be treated like this. > > -- > Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 > Internet Expert | Home: | Fax: +44 870 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 > Thus plc | | > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Fri, 02 Jul 2004 00:40:35 -0400 From: Jeff Williams Date: Fri, 02 Jul 2004 00:40:35 -0400 To: Mike Hammer Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <17086.1088586316@gromit.rfc1035.com> Message-ID: <40E4FEE6.DD73F6B8@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Mike and all, Mike Hammer wrote: > At 08:11 PM 6/30/2004 -0700, Jeff Williams wrote: > >of their personal and private > >data such as their name, ENUM number, address, and direct > >contact phone number. > > Jeff, > > While other elements might be private data, the E.164 number is not. The > E.164 number MUST be visible to enable universal routing of calls to at > least some node that can reach the terminal assigned that E.164 number. Why? I don't agree with your assertion here. As a developer of many years, making universal routing of calls to any node need not require that data to be viewable. I admit freely that it is much easier to code such calls to data that is, however. > > > > The privacy issue is about what OTHER data gets associated with the E.164 > number, that is SPECIFIC to an INDIVIDUAL. Please get this straight in > your mind. Assigned ENUM numbers IS SPECIFIC to an INDIVIDUAL, and as such needs to be protected for good and valid privacy reasons... > > > Mike Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Fri, 02 Jul 2004 03:28:54 -0400 From: "Peter Williams" Date: Fri, 02 Jul 2004 03:28:54 -0400 To: ag at ag-projects.com Subject: Re: [Enum] ldaps and E2U Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO From: Adrian Georgescu To: "Peter Williams" CC: enum at ietf.org Subject: Re: [Enum] ldaps and E2U Date: Thu, 1 Jul 2004 21:49:59 +0200 What would be the role of Active Directory with regards to ENUM? Could you detail on this? (a) use the DNS as a locator for the ENUM providers (of PREMDs), much as we use DNS today to locate ldap access points (with site specific modifiers) of Windows authentication servers (b) use the multi-mastering replication in AD to transfer ENUM zones between primary and secondary ENUM provider's DNS servers (in a PREMD) (c) use Windows 2003 features to target which subset of zones are replicated where by an DNS server acting as a distibution point for a confederation of ENUM providers (each operating a PREMD) (d) dynamically register the ENUM address of a terminal in the PREMD associated with the DHCP assigning the device its primary IP address, and registering the A/PTR in the local DNS name space. Thinking laterally, to get ENUM out of its non-adoption hole. I feel ENUM is exactly where X.509 was in IETF in 1994. On the cusp of a breakthrough. I have every hope the breakout mechanisms that worked then, can work here. On Jul 1, 2004, at 8:29 PM, Peter Williams wrote: One of the URI mappings mentioned in the ENUM RFC is from E.164 to an ldaps URI ; that is ldap (i.e. X.500 in drag) over SSL. Can anyone point me to a E2U client implementation that has an initial DNS lookup then cooperate with ldap(s) (preferably resolved using PRDMD-oriented ActiveDirectory implementation from Microsoft)? Alternatively , has anyone tried to put ENUM NAPTRs in the DNS schema of the active directory, so the directory can act as the responder for E2U queries- and thus benefit from well-understood management domain practices and knowledge distribution techniques for private domain access points? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 02 Jul 2004 10:43:26 -0400 From: Mike Hammer Date: Fri, 02 Jul 2004 10:43:26 -0400 To: Jeff Williams Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <17086.1088586316@gromit.rfc1035.com> Message-ID: <4.3.2.7.2.20040702101724.00b033b0@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 11:21 PM 7/1/2004 -0700, Jeff Williams wrote: Mike and all, Mike Hammer wrote: > At 08:11 PM 6/30/2004 -0700, Jeff Williams wrote: > >of their personal and private > >data such as their name, ENUM number, address, and direct > >contact phone number. > > Jeff, > > While other elements might be private data, the E.164 number is not. The > E.164 number MUST be visible to enable universal routing of calls to at > least some node that can reach the terminal assigned that E.164 number. Why? I don't agree with your assertion here. As a developer of many years, making universal routing of calls to any node need not require that data to be viewable. What is viewable depends on what the software chooses to put on the screen. But, by all means please enlighten me here. How does a gateway from the PSTN attach to the Internet, receive a call from an E.164 number to a target E.164 number route the call, with no pre-assumed relationship with that target? I admit freely that it is much easier to code such calls to data that is, however. > > > > The privacy issue is about what OTHER data gets associated with the E.164 > number, that is SPECIFIC to an INDIVIDUAL. Please get this straight in > your mind. Assigned ENUM numbers IS SPECIFIC to an INDIVIDUAL, and as such needs to be protected for good and valid privacy reasons... So, the PSTN gateway that received the TDM call with a given target E.164 called party address is by nature of receiving an IAM in violation of privacy laws? Please explain at what point in time the privacy violation occurred? When the caller dialed it? When the originating TDM switch queried a NP database indicating it was ported to an IP endpoint? (Or alternatively, the SP queried an internal database, which indicates the number is on its IP network rather than TDM network.) When it reached the PSTN GW? When the PSTN GW queries ENUM and finds the call can be routed to a certain service provider? (This too could be in internal SP database, but for sake of completeness, we need to consider calls that span service providers.) When that service provider translates the anonymous E.164 URI to a user-specific URI? When the INVITE arrives at the called terminal? It's clear we think differently. But, I am trying to understand what you mean, even though I disagree about the legal judgement. Mike > > > Mike Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From iesg-secretary@ietf.org Fri, 02 Jul 2004 11:33:49 -0400 From: "IETF-IESG-Support via RT" Date: Fri, 02 Jul 2004 11:33:49 -0400 To: enum at ietf.org Subject: [Enum] [Inquiry #5546] AutoReply: Affordable Phentermine - All meds delivered overnight In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Affordable Phentermine - All meds delivered overnight", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #5546] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #5546] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary at ietf.org ------------------------------------------------------------------------- This transaction appears to have no content _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From iesg-secretary@ietf.org Fri, 02 Jul 2004 11:33:49 -0400 From: "IETF-IESG-Support via RT" Date: Fri, 02 Jul 2004 11:33:49 -0400 To: enum at ietf.org Subject: [Enum] [Inquiry #5547] AutoReply: Affordable Phentermine - All meds delivered overnight In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Affordable Phentermine - All meds delivered overnight", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #5547] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #5547] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary at ietf.org ------------------------------------------------------------------------- This transaction appears to have no content _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Fri, 02 Jul 2004 23:48:54 -0400 From: Jeff Williams Date: Fri, 02 Jul 2004 23:48:54 -0400 To: Mike Hammer Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <17086.1088586316@gromit.rfc1035.com> Message-ID: <40E6443A.40D40F77@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Make and all, Mike Hammer wrote: > At 11:21 PM 7/1/2004 -0700, Jeff Williams wrote: > >Mike and all, > > > >Mike Hammer wrote: > > > > > At 08:11 PM 6/30/2004 -0700, Jeff Williams wrote: > > > >of their personal and private > > > >data such as their name, ENUM number, address, and direct > > > >contact phone number. > > > > > > Jeff, > > > > > > While other elements might be private data, the E.164 number is not. The > > > E.164 number MUST be visible to enable universal routing of calls to at > > > least some node that can reach the terminal assigned that E.164 number. > > > >Why? I don't agree with your assertion here. As a developer of many years, > >making universal routing of calls to any node need not require that data to > >be viewable. > > What is viewable depends on what the software chooses to put on the > screen. But, by all means please enlighten me here. First of all you did not answer my question I ask in my previously ask, which was "Why?". Could you do that please? Secondly, your right of course, what is viewable does in the case of a call, depend on what the calling software chooses to put on the or any screen. However no call from any calling program that I am aware of requires "Data" to be 'Viewable" as the standards track for ENUM would require in it's present state. Hence privacy of assigned user ENUM's are exposed to hacks unnecessarily and thereby endangering those users to significant damages... > > > How does a gateway from the PSTN attach to the Internet, receive a call > from an E.164 number to a target E.164 number route the call, with no > pre-assumed relationship with that target? It doesn't. And I didn't infer or suggest that it should/could in my previous remarks. I DID suggest that any assigned user ENUM number need not be viewable for such to be routed. There are several techniques by which this can be accomplished, so I will not outline them as to do so would be too verbose for the purposes of this forum. > > > > I admit freely that it is much easier to code such calls to > >data > >that is, however. > > > > > > > > > > > > > > > > The privacy issue is about what OTHER data gets associated with the E.164 > > > number, that is SPECIFIC to an INDIVIDUAL. Please get this straight in > > > your mind. > > > > Assigned ENUM numbers IS SPECIFIC to an INDIVIDUAL, and as such > >needs to be protected for good and valid privacy reasons... > > So, the PSTN gateway that received the TDM call with a given target E.164 > called party address is by nature of receiving an IAM in violation of > privacy laws? In short, yes. > > > Please explain at what point in time the privacy violation occurred? At the time the user ENUM is assigned and the user associated with that number is not allowed to opt-out for said assigned number as to be non-viewable.. > > > When the caller dialed it? > > When the originating TDM switch queried a NP database indicating it was > ported to an IP endpoint? (Or alternatively, the SP queried an internal > database, which indicates the number is on its IP network rather than TDM > network.) > > When it reached the PSTN GW? > > When the PSTN GW queries ENUM and finds the call can be routed to a certain > service provider? (This too could be in internal SP database, but for sake > of completeness, we need to consider calls that span service providers.) > > When that service provider translates the anonymous E.164 URI to a > user-specific URI? > > When the INVITE arrives at the called terminal? > > It's clear we think differently. But, I am trying to understand what you > mean, even though I disagree about the legal judgement. > > Mike > > > > > > > > > > Mike > > > >Regards, > >-- > >Jeffrey A. Williams > >Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > >"Be precise in the use of words and expect precision from others" - > > Pierre Abelard > > > >"If the probability be called P; the injury, L; and the burden, B; > >liability depends upon whether B is less than L multiplied by > >P: i.e., whether B is less than PL." > >United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > >=============================================================== > >Updated 1/26/04 > >CSO/DIR. Internet Network Eng. SR. Eng. Network data security > >IDNS. div. of Information Network Eng. INEG. INC. > >E-Mail jwkckid1 at ix.netcom.com > > Registered Email addr with the USPS > >Contact Number: 214-244-4827 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From james@seng.cc Tue, 06 Jul 2004 11:47:23 -0400 From: James Seng Date: Tue, 06 Jul 2004 11:47:23 -0400 To: Jim Reid Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <17086.1088586316@gromit.rfc1035.com> Message-ID: <40EA5036.1060901@seng.cc> MIME-Version: 1.0 Content-Type: text/plain Status: RO how about not able to get a delegation needed in e164.arpa? it is like saying we design this wonderful DNS system but no one is able to register anything under it. james Jim Reid wrote: What matters is the operators agree on a domain name for Infrastructure ENUM. This might as well be e164.arpa since (a) it's vendor neutral; (b) already an agreed IETF standard; (c) not controlled by any nation. It's hard to see how any other choice of domain name could be better (technically or politically). And it prevents VoIP/SIP applications from getting schizophrenia from figuring out which domain name they should use based on what network they're running in today. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ag@ag-projects.com Tue, 06 Jul 2004 14:14:54 -0400 From: Adrian Georgescu Date: Tue, 06 Jul 2004 14:14:54 -0400 To: James Seng Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <17086.1088586316@gromit.rfc1035.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO For my understanding, user ENUM consists of already existing telephone numbers already in use by end-users. Provider ENUM consists of blocks of numbers assigned to providers which in term get assigned to end-users. These number ranges if PROPERLY delegated based on existing E164 numbering plans in place in each country do NOT overlap so they could stay in the same tree. Or do they? Adrian On Jul 6, 2004, at 9:09 AM, James Seng wrote: how about not able to get a delegation needed in e164.arpa? it is like saying we design this wonderful DNS system but no one is able to register anything under it. james Jim Reid wrote: What matters is the operators agree on a domain name for Infrastructure ENUM. This might as well be e164.arpa since (a) it's vendor neutral; (b) already an agreed IETF standard; (c) not controlled by any nation. It's hard to see how any other choice of domain name could be better (technically or politically). And it prevents VoIP/SIP applications from getting schizophrenia from figuring out which domain name they should use based on what network they're running in today. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Tue, 06 Jul 2004 14:22:15 -0400 From: Jim Reid Date: Tue, 06 Jul 2004 14:22:15 -0400 To: James Seng Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <40EA5036.1060901@seng.cc> Message-ID: <3790.1089136052@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO >>>>> "James" == James Seng writes: James> how about not able to get a delegation needed in e164.arpa? Huh? If an operator uses a private instance of e164.arpa for call routing or whatever, no delegation is necessary. The telco just creates an internal version of 1.e164.arpa (say) on their network and they're done. That's all. It's that easy. Besides, there are no reasons in principle why delegations are not possible in the *public* e164.arpa tree. [For User ENUM obviously, not Infrastructure ENUM.] Provided the relevant Administration approves the request, any Tier-1 code can be delegated. And anything below that becomes a National Matter. So if you can't get a delegation under your favourite country code, take it up with the authorities in that country. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 06 Jul 2004 16:07:36 -0400 From: "Stastny Richard" Date: Tue, 06 Jul 2004 16:07:36 -0400 To: "Adrian Georgescu" Subject: Re: [Enum] IETF, ENUM and NGN Message-ID: <06CF906FE3998C4E944213062009F1624437D4@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO >These number ranges if PROPERLY delegated based on existing E164 >numbering plans in place in each country do NOT overlap so they could >stay in the same tree. Or do they? Thank you, Adrian for this question. Of course they do overlap. Consider a cable operator has assigned a number block (e.g. UPC) in Vienna: e.g +43 1 979xxxx This is a geographic number. I, as a end-user decide now to opt-in ENUM, so I get a delegation in e164.arpa Now the cable operator goes VoIP and also decides to peer with another cable operator via "provider" ENUM. The two (or more) providers decide to use a separate tree, because they cannot do this in User ENUM (I and others are already there). I could now decide to port the number from UPC to Telekom Austria. This causes the entry in "provider" ENUM either to be removed, or changed to Telekom Austria (if Telekom Austria is also using this tree). My entry in User ENUM is unchanged. They only way to avoid a conflict is a provider using a block in a new number range dedicated for VoIP and selling these numbers together with the ENUM entry (that is, the user is at subscrption time declaring to opt-in ENUM) or the provider is selling single numbers together with ENUM opt-in. Richard -----UrsprÃngliche Nachricht----- Von: Adrian Georgescu [mailto:ag at ag-projects.com] Gesendet: Di 06.07.2004 19:41 An: James Seng Cc: enum at ietf.org Betreff: Re: [Enum] IETF, ENUM and NGN For my understanding, user ENUM consists of already existing telephone numbers already in use by end-users. Provider ENUM consists of blocks of numbers assigned to providers which in term get assigned to end-users. These number ranges if PROPERLY delegated based on existing E164 numbering plans in place in each country do NOT overlap so they could stay in the same tree. Or do they? Adrian _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Thu, 08 Jul 2004 15:52:39 -0400 From: Mike Hammer Date: Thu, 08 Jul 2004 15:52:39 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <4.3.2.7.2.20040707121316.02f9d468@cia.cisco.com> Message-ID: <4.3.2.7.2.20040708113805.03c471d8@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Lawrence, Do I understand correctly that ENUM points to your sip: address, and that the DNS holds records to go from sip address to IP address to make the connection to your SIP proxy? I would anticipate also the possibility that the domain name of your SIP address could be provided by either a residential SP or your company acting as SP. I assume that you are also getting the IP address from your local ISP serving your home, although I'm a bit fuzzy on what type of local access you might be using to connect to the ISP (modem, DSL, cable?). Note that I consider enterprises/companies as service providers, though not publicly regulated ones. And while they could also make use of ENUM, they might question the value versus risk of putting their company directory into the public domain. I suspect that they would want to keep that information internal and only selectively release such information. However, the before-mentioned suggestion to provide a SIP proxy domain such that SIP messages to sip:@company.com that can use an internal database to translate to user-specific sip address can be used. When presence becomes more widely deployed, ENUM could point to the presence address for subscriptions. Then presence information could provide the remaining information that would otherwise be publicly posted in ENUM. Mike At 11:27 PM 7/7/2004 +0100, Conroy, Lawrence (SMTP) wrote: Hi Mike, folks, Is this 90% valid? My IAD (Intertex IX66) at home is a SIP proxy - it's just easier to do this than play around trying to get SIP-unaware Router/Firewall/NAT boxes to work (particularly if they assume I'm using a Pissy and Windoze to configure things). Thus I don't fall into the 90% - I have better things to do with my time. I contend that there is a business case for Corporates to make ENUM registrations for their number ranges. I'm not completely convinced about residential customers, but for Corporates, it's a "slam dunk". These will almost certainly be running SIP proxies (at least your company and mine hope so :). Thus, whilst you may be right on the total population of PSTN telephone service subscribers, I'm not sure this is the case for the population of "user" ENUM subscribers. all the best, Lawrence On 7 Jul 2004, at 17:23, Mike Hammer wrote: Richard, OK, let me back up one step. My comment was oriented to the simplest case, where 90% of the user population would not likely run their own SIP proxies and act as service providers for themselves, nor possibly add in additional SPs. My point was more toward the idea that when they "port" the number to a different SP, chances are the target address of a SIP proxy supporting that user would be different. -- Visit our website at www.roke.co.uk Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK. The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Thu, 08 Jul 2004 22:13:22 -0400 From: "Conroy, Lawrence (SMTP)" Date: Thu, 08 Jul 2004 22:13:22 -0400 To: Mike Hammer Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <4.3.2.7.2.20040707121316.02f9d468@cia.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Mike, folks, I'm slightly at a loss here. I fear that we will just have to disagree on this one. You seem to be asking if I have a E2U+sip entry. The answer to that is "some of the time, yes". You then ask what kind of access I have. The domain of the SIP address is mine; I registered it. As it happens, the domain of the domainpart of the SIP AoRs "at work" was also registered by me. The IP address range I have at home was assigned via my DSL Internet Access Provider. My company's IAP also arranged for the IP range used by my company. I have to ask, "this is pertinent because...?". I must disagree over your definition of an Enterprise as a Service Provider. An Enterprise can register ENUM domains for the E.164 numbers via which it is provided Communications Service by a 3rd party CSP. It is the end user assignee for these E.164 numbers, and so a ->potential<- ENUM Registrant. The CSP is not the end user, and so (on this side of the pond) cannot register ENUM domains for those E.164 numbers. Once registered, if I (or my company) choose to put anything I/they want into my/their ENUM domains, then (as I/they are paying to have it published) that's my/their choice. Given that any reasonable DNS server handles "split horizon", what you see may well not be what I see. Again, that's my/their choice. Whether or not my company allows IP calls from teleworkers or Extranet partners is also our choice. Other registrants can make different choices in their domains - I'm not stopping them and they're not stopping me. Equally, if an Enterprise chooses not to register in ENUM, that's also their choice. Finally, if and when caller/callee prefs and the rest of the infrastructure is standardised and in place to give all of the UCI/PUA features, then one could have a single entry in ENUM pointing to that PUA. However, for some time, there will be SIP systems (or H.323, just to be non-denominational) that do not provide full PUA functionality, and for the foreseeable future (i.e. in the interim) just using ENUM (and standard DNS) alone works for me. I don't need anything more complex. My point is just that I believe that it will work for more than 10% of the Registrant population. all the best, Lawrence On 8 Jul 2004, at 16:51, Mike Hammer wrote: Lawrence, Do I understand correctly that ENUM points to your sip: address, and that the DNS holds records to go from sip address to IP address to make the connection to your SIP proxy? I would anticipate also the possibility that the domain name of your SIP address could be provided by either a residential SP or your company acting as SP. I assume that you are also getting the IP address from your local ISP serving your home, although I'm a bit fuzzy on what type of local access you might be using to connect to the ISP (modem, DSL, cable?). Note that I consider enterprises/companies as service providers, though not publicly regulated ones. And while they could also make use of ENUM, they might question the value versus risk of putting their company directory into the public domain. I suspect that they would want to keep that information internal and only selectively release such information. However, the before-mentioned suggestion to provide a SIP proxy domain such that SIP messages to sip:@company.com that can use an internal database to translate to user-specific sip address can be used. When presence becomes more widely deployed, ENUM could point to the presence address for subscriptions. Then presence information could provide the remaining information that would otherwise be publicly posted in ENUM. Mike At 11:27 PM 7/7/2004 +0100, Conroy, Lawrence (SMTP) wrote: Hi Mike, folks, Is this 90% valid? Thus, whilst you may be right on the total population of PSTN telephone service subscribers, I'm not sure this is the case for the population of "user" ENUM subscribers. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 09 Jul 2004 10:25:18 -0400 From: Mike Hammer Date: Fri, 09 Jul 2004 10:25:18 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <4.3.2.7.2.20040708113805.03c471d8@cia.cisco.com> Message-ID: <4.3.2.7.2.20040709095512.00b03b68@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Lawrence, I don't think what you and I are saying is that much at odds. My comment about the 90% was that the general population (not the technical saavy) will follow the conventions of their residential service provider or employer company providing the access network, the IP addresses, the SIP or H.323 addresses, and the database entries to make it all work. This does not mean that there can not be other configurations that also work as you point out. But, the majority of people don't have the time, interest, or background to go figure it all out. I mentioned the access provider and the IP addresses only to complete the picture. There is a series of things that must be in place before the system works. If I put a private non-routable IP address from the LAN in my house in an ENUM record, I won't get an incoming call. As for whether a company is a service provider, if they give me a network connection, an IP address, a SIP address, and route packets to my laptop, and terminate calls to my VoIP phone ... there is a saying on this side of the pond: If it waddles like a duck, swims like a duck, quacks like a duck, and looks like a duck, it's a duck. Mike At 01:14 AM 7/9/2004 +0100, Conroy, Lawrence (SMTP) wrote: Hi Mike, folks, I'm slightly at a loss here. I fear that we will just have to disagree on this one. You seem to be asking if I have a E2U+sip entry. The answer to that is "some of the time, yes". You then ask what kind of access I have. The domain of the SIP address is mine; I registered it. As it happens, the domain of the domainpart of the SIP AoRs "at work" was also registered by me. The IP address range I have at home was assigned via my DSL Internet Access Provider. My company's IAP also arranged for the IP range used by my company. I have to ask, "this is pertinent because...?". I must disagree over your definition of an Enterprise as a Service Provider. An Enterprise can register ENUM domains for the E.164 numbers via which it is provided Communications Service by a 3rd party CSP. It is the end user assignee for these E.164 numbers, and so a ->potential<- ENUM Registrant. The CSP is not the end user, and so (on this side of the pond) cannot register ENUM domains for those E.164 numbers. Once registered, if I (or my company) choose to put anything I/they want into my/their ENUM domains, then (as I/they are paying to have it published) that's my/their choice. Given that any reasonable DNS server handles "split horizon", what you see may well not be what I see. Again, that's my/their choice. Whether or not my company allows IP calls from teleworkers or Extranet partners is also our choice. Other registrants can make different choices in their domains - I'm not stopping them and they're not stopping me. Equally, if an Enterprise chooses not to register in ENUM, that's also their choice. Finally, if and when caller/callee prefs and the rest of the infrastructure is standardised and in place to give all of the UCI/PUA features, then one could have a single entry in ENUM pointing to that PUA. However, for some time, there will be SIP systems (or H.323, just to be non-denominational) that do not provide full PUA functionality, and for the foreseeable future (i.e. in the interim) just using ENUM (and standard DNS) alone works for me. I don't need anything more complex. My point is just that I believe that it will work for more than 10% of the Registrant population. all the best, Lawrence On 8 Jul 2004, at 16:51, Mike Hammer wrote: Lawrence, Do I understand correctly that ENUM points to your sip: address, and that the DNS holds records to go from sip address to IP address to make the connection to your SIP proxy? I would anticipate also the possibility that the domain name of your SIP address could be provided by either a residential SP or your company acting as SP. I assume that you are also getting the IP address from your local ISP serving your home, although I'm a bit fuzzy on what type of local access you might be using to connect to the ISP (modem, DSL, cable?). Note that I consider enterprises/companies as service providers, though not publicly regulated ones. And while they could also make use of ENUM, they might question the value versus risk of putting their company directory into the public domain. I suspect that they would want to keep that information internal and only selectively release such information. However, the before-mentioned suggestion to provide a SIP proxy domain such that SIP messages to sip:@company.com that can use an internal database to translate to user-specific sip address can be used. When presence becomes more widely deployed, ENUM could point to the presence address for subscriptions. Then presence information could provide the remaining information that would otherwise be publicly posted in ENUM. Mike At 11:27 PM 7/7/2004 +0100, Conroy, Lawrence (SMTP) wrote: Hi Mike, folks, Is this 90% valid? Thus, whilst you may be right on the total population of PSTN telephone service subscribers, I'm not sure this is the case for the population of "user" ENUM subscribers. -- Visit our website at www.roke.co.uk Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK. The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Fri, 09 Jul 2004 16:13:32 -0400 From: "Pfautz, Penn L, ALABS" Date: Fri, 09 Jul 2004 16:13:32 -0400 To: Subject: [Enum] new I-D on carrier ENUM Message-ID: <34DA635B184A644DA4588E260EC0A25A079B4FDF@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO For those not on i-d announce... -----Original Message----- From: i-d-announce-bounces at ietf.org [mailto:i-d-announce-bounces at ietf.org] On Behalf Of Internet-Drafts at ietf.org Sent: Friday, July 09, 2004 11:28 AM To: i-d-announce at ietf.org Subject: I-D ACTION:draft-pfautz-lind-enum-carrier-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Combined User/Carrier ENUM Author(s) : P. Pfautz, S. Lind Filename : draft-pfautz-lind-enum-carrier-00.txt Pages : 5 Date : 2004-7-8 This document considers how so-called "carrier" or "infrastructure" ENUM and "end user" or "public" ENUM can share a single Tier 1 registry yet have independent Tier 2 providers. This approach allows the common cooperative infrastructure required by ENUM to be shared by end users and carriers reducing costs and facilitating adoption of ENUM generally. The essence of the proposal is to populate the Tier 1 registry with non-terminal NAPTRs rather than NS records and use different ENUM service fields for carrier and end user records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pfautz-lind-enum-carrier-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-pfautz-lind-enum-carrier-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. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 09 Jul 2004 22:34:03 -0400 From: Richard Shockey Date: Fri, 09 Jul 2004 22:34:03 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-00.txt Message-ID: <6.1.0.6.2.20040709194213.03990c10@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Fri, 09 Jul 2004 11:27:43 -0400 Subject: I-D ACTION:draft-pfautz-lind-enum-carrier-00.txt X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Combined User/Carrier ENUM Author(s) : P. Pfautz, S. Lind Filename : draft-pfautz-lind-enum-carrier-00.txt Pages : 5 Date : 2004-7-8 This document considers how so-called "carrier" or "infrastructure" ENUM and "end user" or "public" ENUM can share a single Tier 1 registry yet have independent Tier 2 providers. This approach allows the common cooperative infrastructure required by ENUM to be shared by end users and carriers reducing costs and facilitating adoption of ENUM generally. The essence of the proposal is to populate the Tier 1 registry with non-terminal NAPTRs rather than NS records and use different ENUM service fields for carrier and end user records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pfautz-lind-enum-carrier-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-pfautz-lind-enum-carrier-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: <2004-7-9115145.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-pfautz-lind-enum-carrier-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Sat, 10 Jul 2004 10:06:16 -0400 From: James Seng Date: Sat, 10 Jul 2004 10:06:16 -0400 To: Mike Hammer Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <4.3.2.7.2.20040708113805.03c471d8@cia.cisco.com> Message-ID: <40EFF66B.3020802@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: RO I been watching this discussion with a little bit of interest. Seem like there is a disagreement but really, it is just a unsync discussion, where one is talking about User ENUM and another Infrastructure/Carrier ENUM. This is why we should probably get at least the definition nails down before the next IETF so we can have a more productive mini-BoF on infrastructure carrier ENUM. (User ENUM issues as I understand will be discussed in the session before). Speaking of the mini-BoF, for those who has interest to speak, please send an email to Richard Stastny and myself. Ideally, you should already have an I-D. Please do so by next week so we can arrange the agenda. We are also looking for a volunteer for scribes (two preferably). ps: So far on the agenda, we have something from Patrick/Richard giving problem statement, Stastny will give a background and Penn/Steve already indicated they have something to contribute. -James Seng Mike Hammer wrote: Lawrence, I don't think what you and I are saying is that much at odds. My comment about the 90% was that the general population (not the technical saavy) will follow the conventions of their residential service provider or employer company providing the access network, the IP addresses, the SIP or H.323 addresses, and the database entries to make it all work. This does not mean that there can not be other configurations that also work as you point out. But, the majority of people don't have the time, interest, or background to go figure it all out. I mentioned the access provider and the IP addresses only to complete the picture. There is a series of things that must be in place before the system works. If I put a private non-routable IP address from the LAN in my house in an ENUM record, I won't get an incoming call. As for whether a company is a service provider, if they give me a network connection, an IP address, a SIP address, and route packets to my laptop, and terminate calls to my VoIP phone ... there is a saying on this side of the pond: If it waddles like a duck, swims like a duck, quacks like a duck, and looks like a duck, it's a duck. Mike At 01:14 AM 7/9/2004 +0100, Conroy, Lawrence (SMTP) wrote: Hi Mike, folks, I'm slightly at a loss here. I fear that we will just have to disagree on this one. You seem to be asking if I have a E2U+sip entry. The answer to that is "some of the time, yes". You then ask what kind of access I have. The domain of the SIP address is mine; I registered it. As it happens, the domain of the domainpart of the SIP AoRs "at work" was also registered by me. The IP address range I have at home was assigned via my DSL Internet Access Provider. My company's IAP also arranged for the IP range used by my company. I have to ask, "this is pertinent because...?". I must disagree over your definition of an Enterprise as a Service Provider. An Enterprise can register ENUM domains for the E.164 numbers via which it is provided Communications Service by a 3rd party CSP. It is the end user assignee for these E.164 numbers, and so a ->potential<- ENUM Registrant. The CSP is not the end user, and so (on this side of the pond) cannot register ENUM domains for those E.164 numbers. Once registered, if I (or my company) choose to put anything I/they want into my/their ENUM domains, then (as I/they are paying to have it published) that's my/their choice. Given that any reasonable DNS server handles "split horizon", what you see may well not be what I see. Again, that's my/their choice. Whether or not my company allows IP calls from teleworkers or Extranet partners is also our choice. Other registrants can make different choices in their domains - I'm not stopping them and they're not stopping me. Equally, if an Enterprise chooses not to register in ENUM, that's also their choice. Finally, if and when caller/callee prefs and the rest of the infrastructure is standardised and in place to give all of the UCI/PUA features, then one could have a single entry in ENUM pointing to that PUA. However, for some time, there will be SIP systems (or H.323, just to be non-denominational) that do not provide full PUA functionality, and for the foreseeable future (i.e. in the interim) just using ENUM (and standard DNS) alone works for me. I don't need anything more complex. My point is just that I believe that it will work for more than 10% of the Registrant population. all the best, Lawrence On 8 Jul 2004, at 16:51, Mike Hammer wrote: Lawrence, Do I understand correctly that ENUM points to your sip: address, and that the DNS holds records to go from sip address to IP address to make the connection to your SIP proxy? I would anticipate also the possibility that the domain name of your SIP address could be provided by either a residential SP or your company acting as SP. I assume that you are also getting the IP address from your local ISP serving your home, although I'm a bit fuzzy on what type of local access you might be using to connect to the ISP (modem, DSL, cable?). Note that I consider enterprises/companies as service providers, though not publicly regulated ones. And while they could also make use of ENUM, they might question the value versus risk of putting their company directory into the public domain. I suspect that they would want to keep that information internal and only selectively release such information. However, the before-mentioned suggestion to provide a SIP proxy domain such that SIP messages to sip:@company.com that can use an internal database to translate to user-specific sip address can be used. When presence becomes more widely deployed, ENUM could point to the presence address for subscriptions. Then presence information could provide the remaining information that would otherwise be publicly posted in ENUM. Mike At 11:27 PM 7/7/2004 +0100, Conroy, Lawrence (SMTP) wrote: Hi Mike, folks, Is this 90% valid? Thus, whilst you may be right on the total population of PSTN telephone service subscribers, I'm not sure this is the case for the population of "user" ENUM subscribers. -- Visit our website at www.roke.co.uk Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK. The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@eunet.at Sat, 10 Jul 2004 13:23:31 -0400 From: Michael Haberler Date: Sat, 10 Jul 2004 13:23:31 -0400 To: "Pfautz, Penn L, ALABS" Subject: Re: [Enum] new I-D on carrier ENUM In-Reply-To: <34DA635B184A644DA4588E260EC0A25A079B4FDF@ACCLUST02EVS1.ugd.att.com> Message-ID: <6.1.2.0.2.20040710185117.0317c218@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: RO Penn, Steve, that is an interesting idea. However, I doubt wether it solves the problem which I believe hinders adoption and was the reason for the infrastructure ENUM discussion in the first place. It seems to me the main reason why ITSP's are pushing for a *non* e164.arpa tree solution is that with the current thinking behind user ENUM, namely user opt-in, and in particular beforehand government opt-in will result in an extremely slow overall adoption curve, and consequently ridiculously low resolution rates for a long time to come. Bypassing the adoption of user opt-in is half the story if you're still supposed to hold E2C entries in a national subtree of e164.arpa - because basically all 184+ governments are still asleep at the switch (give and take some). And that isnt going to change soon. If the underlying problem is the growth speed of the e164.arpa tree at the national level, it doesnt help in terms of footprint to decorate the occasional subtree therunder with a different type of attribute since the problem a level up remains unaddressed. WRT the user opt-in idea, I can assure you my experience that as soon as an operator decides to support user ENUM it will very much look like operator opt-in in the first place - for the simple reasons they will have to support it, and it cannot, at this point in time, sold as a per-user service attribute to the general public. The first thing which happens is a change in ITSP terms&conditions that users "agree to opt-in", which IMO is the only viable option to start with. What I'm saying is - if you have public ENUM with any reasonable stab at market share with the VoIP operators, the need for a dual-mode solution diminishes fast - the only reason left is "controlled peering". If you dont have public ENUM, your proposal wont help too much because it assumes a cc Tier1 delegation in the first place. Unfortunately it doesnt help if one is part of the "lucky ones" because I'm coming to believe that the winning strategy still is the one which gets coverage fastest. Given governments in the loop, it's hard to see how this can be anything in e164.arpa. -Michael At 21:39 09.07.2004, Pfautz, Penn L, ALABS wrote: For those not on i-d announce... -----Original Message----- From: i-d-announce-bounces at ietf.org [mailto:i-d-announce-bounces at ietf.org] On Behalf Of Internet-Drafts at ietf.org Sent: Friday, July 09, 2004 11:28 AM To: i-d-announce at ietf.org Subject: I-D ACTION:draft-pfautz-lind-enum-carrier-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Combined User/Carrier ENUM Author(s) : P. Pfautz, S. Lind Filename : draft-pfautz-lind-enum-carrier-00.txt Pages : 5 Date : 2004-7-8 This document considers how so-called "carrier" or "infrastructure" ENUM and "end user" or "public" ENUM can share a single Tier 1 registry yet have independent Tier 2 providers. This approach allows the common cooperative infrastructure required by ENUM to be shared by end users and carriers reducing costs and facilitating adoption of ENUM generally. The essence of the proposal is to populate the Tier 1 registry with non-terminal NAPTRs rather than NS records and use different ENUM service fields for carrier and end user records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-00.txt _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Sat, 10 Jul 2004 14:41:41 -0400 From: Jim Reid Date: Sat, 10 Jul 2004 14:41:41 -0400 To: Michael Haberler Subject: Re: [Enum] new I-D on carrier ENUM In-Reply-To: <6.1.2.0.2.20040710185117.0317c218@localhost> Message-ID: <11706.1089484547@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO >>>>> "Michael" == Michael Haberler writes: Michael> It seems to me the main reason why ITSP's are pushing for Michael> a *non* e164.arpa tree solution is that with the current Michael> thinking behind user ENUM, namely user opt-in, and in Michael> particular beforehand government opt-in will result in an Michael> extremely slow overall adoption curve, and consequently Michael> ridiculously low resolution rates for a long time to Michael> come. Your perception may be right. But the rationale for a non e164.arpa solution is wrong IMO. A domain name should not be confused with an instantiaton of its name space on the public internet. It seems that some people on this list are unaware of that distinction or are choosing to ignore it. ITSPs -- whatever they are -- can perfectly set up their own private instances of e164.arpa today and populate that with whatever they want however they like. Provided that private tree isn't visible on the internet and doesn't get confused with the public e164.arpa tree, there's no problem. We're done. These ITSPs can just do it. They don't have to ask anyone's permission. Or get a new TLD from ICANN. These ITSPs will presumably want a private tree anyway so they don't disclose customer data or their network operations to competitors, avoid privacy & data protection complications, get round restrictions surrounding the use of the public tree, etc, etc. I simply cannot understand what advantages there are to having a private tree under some other to-be-agreed domain name that cannot be met by a private tree under e164.arpa. Remember that's the domain name IETF has decided gets used for ENUM. Could somebody *please* tell me what they can achieve under this mythical private tree that they could not achieve under a their own private e164.arpa tree? In fact, choosing another domain name is fraught with complications. Like choosing who will own and administer it. Or where that domain name would sit in the DNS. [Hey, let's put this private tree under JimsPrivateENUMTree.com and then watch the fun when I forget to renew the domain name registration with Verisign.] Or what controls the domain's owner would be able to apply and how they'd be policed. BTW, I think that choosing another domain name for a private tree will just add complexity and confusion, especially for applications. That will also hamper the update of ENUM and flatten the adoption curve. Somebody needs to state the glaringly obvious. Since nobody else has, here goes. No matter where an application lives -- inside a telco's net, on the public internet, in an intranet or extranet -- it must only make exactly 1 DNS lookup of exactly 1 domain name to figure out how a "call" gets routed. [That has to be the goal for ENUM, no matter whether it's User ENUM or Infrastructure ENUM or Operator ENUM, however these terms are understood.] After all, that's how the DNS works. Now when the application makes that lookup, it doesn't necessarily go to one set of name servers providing all three same name spaces. In a telco's net, the application queries the telco's DNS infrastructure which directs them to the telco's e164.arpa tree. On the internet, the application would see the public tree for e164.arpa. And on a corporate net, the application sees the company's private instance of e164.arpa because it queries the company's internal DNS infrastructure. It all just works. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Sat, 10 Jul 2004 20:40:27 -0400 From: Jeff Williams Date: Sat, 10 Jul 2004 20:40:27 -0400 To: Michael Haberler Subject: Re: [Enum] new I-D on carrier ENUM In-Reply-To: <34DA635B184A644DA4588E260EC0A25A079B4FDF@ACCLUST02EVS1.ugd.att.com> Message-ID: <40F0A556.4A55ACFA@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Michael and all, Opt-out provisions for User-Enum must be made available as part of the standards track. It is not currently for reasons that have been made obvious on this forum which are rooted in Anti-privacy bigots driving the standards track. If such political ideology based standards tracks continue within the IETF, let alone ENUM, not only will exceptance be hard to come by, legal actions will proliferate and an alarming rate. Michael Haberler wrote: > Penn, Steve, > > that is an interesting idea. However, I doubt wether it solves the problem > which I believe hinders adoption and was the reason for the infrastructure > ENUM discussion in the first place. > > It seems to me the main reason why ITSP's are pushing for a *non* e164.arpa > tree solution is that with the current thinking behind user ENUM, namely > user opt-in, and in particular beforehand government opt-in will result in > an extremely slow overall adoption curve, and consequently ridiculously low > resolution rates for a long time to come. > > Bypassing the adoption of user opt-in is half the story if you're still > supposed to hold E2C entries in a national subtree of e164.arpa - because > basically all 184+ governments are still asleep at the switch (give and > take some). And that isnt going to change soon. > > If the underlying problem is the growth speed of the e164.arpa tree at the > national level, it doesnt help in terms of footprint to decorate the > occasional subtree therunder with a different type of attribute since the > problem a level up remains unaddressed. > > WRT the user opt-in idea, I can assure you my experience that as soon as an > operator decides to support user ENUM it will very much look like operator > opt-in in the first place - for the simple reasons they will have to > support it, and it cannot, at this point in time, sold as a per-user > service attribute to the general public. The first thing which happens is a > change in ITSP terms&conditions that users "agree to opt-in", which IMO is > the only viable option to start with. > > What I'm saying is - if you have public ENUM with any reasonable stab at > market share with the VoIP operators, the need for a dual-mode solution > diminishes fast - the only reason left is "controlled peering". > > If you dont have public ENUM, your proposal wont help too much because it > assumes a cc Tier1 delegation in the first place. > > Unfortunately it doesnt help if one is part of the "lucky ones" because I'm > coming to believe that the winning strategy still is the one which gets > coverage fastest. Given governments in the loop, it's hard to see how this > can be anything in e164.arpa. > > -Michael > > At 21:39 09.07.2004, Pfautz, Penn L, ALABS wrote: > > >For those not on i-d announce... > >-----Original Message----- > >From: i-d-announce-bounces at ietf.org [mailto:i-d-announce-bounces at ietf.org] > >On Behalf Of Internet-Drafts at ietf.org > >Sent: Friday, July 09, 2004 11:28 AM > >To: i-d-announce at ietf.org > >Subject: I-D ACTION:draft-pfautz-lind-enum-carrier-00.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : A Combined User/Carrier ENUM > > Author(s) : P. Pfautz, S. Lind > > Filename : draft-pfautz-lind-enum-carrier-00.txt > > Pages : 5 > > Date : 2004-7-8 > > > >This document considers how so-called "carrier" or > > "infrastructure" ENUM and "end user" or "public" ENUM can share a > > single Tier 1 registry yet have independent Tier 2 providers. This > > approach allows the common cooperative infrastructure required by > > ENUM to be shared by end users and carriers reducing costs and > > facilitating adoption of ENUM generally. The essence of the > > proposal is to populate the Tier 1 registry with non-terminal > > NAPTRs rather than NS records and use different ENUM service > > fields for carrier and end user records. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-00.txt > > ------------------------------------------------------------------------ > > Part 1.2 Type: Plain Text (text/plain) > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From md@bts.sk Sun, 11 Jul 2004 04:31:49 -0400 From: Marian Durkovic Date: Sun, 11 Jul 2004 04:31:49 -0400 To: Jim Reid Subject: Re: [Enum] new I-D on carrier ENUM In-Reply-To: <6.1.2.0.2.20040710185117.0317c218@localhost> Message-ID: <20040711082351.GA7202@us.svf.stuba.sk> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Sat, Jul 10, 2004 at 07:35:47PM +0100, Jim Reid wrote: > Could somebody *please* tell me what they can > achieve under this mythical private tree that they could not achieve > under a their own private e164.arpa tree? As I wrote before, access to _both_ public and private tree at the same time. > Now when the application makes that lookup, it doesn't necessarily go > to one set of name servers providing all three same name spaces. In a > telco's net, the application queries the telco's DNS infrastructure > which directs them to the telco's e164.arpa tree. On the internet, the > application would see the public tree for e164.arpa. And on a > corporate net, the application sees the company's private instance of > e164.arpa because it queries the company's internal DNS > infrastructure. It all just works. No, it doesn't. By establishing private instance of e164.arpa all data in public e164.arpa is lost. Suppose the company you mention has internal preference to: A) query public ENUM tree and use it if record present B) route all calls for +1234... towards telcoa.com C) route all calls for +4212... towards tecomb.com ...... Z) fallback to PSTN for anything else To ensure B), C) and possibly more, the company needs to establish infrastructure ENUM tree. If it places those records into private e164.arpa like this: *.4.3.2.1.e164.arpa. pointing to telcoa.com *.2.1.2.4.e164.arpa. pointing to telcob.com ..... this private e164.arpa overlays the public e164.arpa., information in it is lost and there's no way to take care of step A). With kind regards, M. -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md at bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Sun, 11 Jul 2004 17:07:22 -0400 From: Richard Shockey Date: Sun, 11 Jul 2004 17:07:22 -0400 To: Jeff Williams Subject: Re: [Enum] new I-D on carrier ENUM In-Reply-To: <34DA635B184A644DA4588E260EC0A25A079B4FDF@ACCLUST02EVS1.ugd.att.com> Message-ID: <6.1.0.6.2.20040711164413.042053c8@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 10:26 PM 7/10/2004, you wrote: Michael and all, Opt-out provisions for User-Enum must be made available as part of the standards track. It is not currently for reasons that have been made obvious on this forum which are rooted in Anti-privacy bigots driving the standards track. Watch it you are starting to cross the line here. This is your first warning. The chairs will not tolerate the discussion degenerating into flatulent name calling. Opt-Out provisions like all administrative issues within the e164.arpa tree are nation state issues associated with their portions of the E.164 plan. Take your complaint to the ITU. If such political ideology based standards tracks continue within the IETF, let alone ENUM, not only will exceptance be hard to come by, legal actions will proliferate and an alarming rate. Michael Haberler wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Sun, 11 Jul 2004 17:07:23 -0400 From: Richard Shockey Date: Sun, 11 Jul 2004 17:07:23 -0400 To: James Seng Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <4.3.2.7.2.20040708113805.03c471d8@cia.cisco.com> Message-ID: <6.1.0.6.2.20040711164155.0401bec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 10:00 AM 7/10/2004, James Seng wrote: I been watching this discussion with a little bit of interest. Seem like there is a disagreement but really, it is just a unsync discussion, where one is talking about User ENUM and another Infrastructure/Carrier ENUM. This is why we should probably get at least the definition nails down before the next IETF so we can have a more productive mini-BoF on infrastructure carrier ENUM. (User ENUM issues as I understand will be discussed in the session before). Speaking of the mini-BoF, for those who has interest to speak, please send an email to Richard Stastny and myself. Ideally, you should already have an I-D. Please do so by next week so we can arrange the agenda. Thank you .. let me second James's note here to the entire list. We are also looking for a volunteer for scribes (two preferably). ps: So far on the agenda, we have something from Patrick/Richard giving problem statement, Very quick statement .. Stastny will give a background and Penn/Steve already indicated they have something to contribute. -James Seng Mike Hammer wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Mon, 12 Jul 2004 01:41:16 -0400 From: Jeff Williams Date: Mon, 12 Jul 2004 01:41:16 -0400 To: Richard Shockey Subject: Re: [Enum] new I-D on carrier ENUM In-Reply-To: <34DA635B184A644DA4588E260EC0A25A079B4FDF@ACCLUST02EVS1.ugd.att.com> Message-ID: <40F23CA6.477F736@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Richard and all, No the opt-out with respect to privacy is a common practice in many areas of many industries and a defacto-standard in quite a few of them such a listing phone numbers, which has already been discussed and recognized on this forum, as well as in the financial credit industry. Hence your quip below appears to be more akin to a errant remark referencing the ITU. Hence any IETF standards track that seeks to disconnect pricacy/security from good common existing practice at the expense of stakeholders/users is at least not appropriate, but also irresponsible. Richard Shockey wrote: > At 10:26 PM 7/10/2004, you wrote: > > >Michael and all, > > > > Opt-out provisions for User-Enum must be made available as part of the > >standards track. It is not currently for reasons that have been made > >obvious on this forum which are rooted in Anti-privacy bigots driving > >the standards track. > > Watch it you are starting to cross the line here. This is your first > warning. The chairs will not tolerate the discussion degenerating into > flatulent name calling. > > Opt-Out provisions like all administrative issues within the e164.arpa tree > are nation state issues associated with their portions of the E.164 plan. > Take your complaint to the ITU. > > > If such political ideology based standards tracks > >continue within the IETF, let alone ENUM, not only will exceptance > >be hard to come by, legal actions will proliferate and an alarming rate. > > > >Michael Haberler wrote: > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From james@seng.cc Mon, 12 Jul 2004 07:48:24 -0400 From: James Seng Date: Mon, 12 Jul 2004 07:48:24 -0400 To: Mike Hammer Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <4.3.2.7.2.20040708113805.03c471d8@cia.cisco.com> Message-ID: <40EF20E5.4000808@seng.cc> MIME-Version: 1.0 Content-Type: text/plain Status: RO I been watching this discussion with a little bit of interest. Seem like there is a disagreement but really, it is just a unsync discussion, where one is talking about User ENUM and another Infrastructure/Carrier ENUM. This is why we should probably get at least the definition nails down before the next IETF so we can have a more productive mini-BoF on infrastructure carrier ENUM. (User ENUM issues as I understand will be discussed in the session before). Speaking of the mini-BoF, for those who has interest to speak, please send an email to Richard Stastny and myself. Ideally, you should already have an I-D. Please do so by next week so we can arrange the agenda. We are also looking for a volunteer for scribes (two preferably). ps: So far on the agenda, we have something from Patrick/Richard giving problem statement, Stastny will give a background and Penn/Steve already indicated they have something to contribute. -James Seng Mike Hammer wrote: My comment about the 90% was that the general population (not the technical saavy) will follow the conventions of their residential service provider or employer company providing the access network, the IP addresses, the SIP or H.323 addresses, and the database entries to make it all work. This does not mean that there can not be other configurations that also work as you point out. But, the majority of people don't have the time, interest, or background to go figure it all out. I mentioned the access provider and the IP addresses only to complete the picture. There is a series of things that must be in place before the system works. If I put a private non-routable IP address from the LAN in my house in an ENUM record, I won't get an incoming call. As for whether a company is a service provider, if they give me a network connection, an IP address, a SIP address, and route packets to my laptop, and terminate calls to my VoIP phone ... there is a saying on this side of the pond: If it waddles like a duck, swims like a duck, quacks like a duck, and looks like a duck, it's a duck. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Mon, 12 Jul 2004 15:47:10 -0400 From: Internet-Drafts@ietf.org Date: Mon, 12 Jul 2004 15:47:10 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-experiences-00.txt Message-ID: <200407121938.PAA05054@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: RO 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 : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-00.txt Pages : 0 Date : 2004-7-12 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-experiences-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-experiences-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon, 12 Jul 2004 19:31:42 -0400 From: Richard Shockey Date: Mon, 12 Jul 2004 19:31:42 -0400 To: enum at ietf.org Subject: [Enum] Fwd: Protocol Action: 'IFAX service of ENUM' to Proposed Standard Message-ID: <6.1.0.6.2.20040712161524.0420fec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO X-test-idtracker: no From: The IESG To: IETF-Announce Date: Mon, 12 Jul 2004 14:24:56 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Cc: Internet Architecture Board , fax chair , fax chair , fax mailing list , RFC Editor Subject: Protocol Action: 'IFAX service of ENUM' to Proposed Standard X-BeenThere: ietf-announce at ietf.org X-Mailman-Version: 2.1.5 List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-announce-bounces at ietf.org The IESG has approved the following document: - 'IFAX service of ENUM ' as a Proposed Standard This document is the product of the Internet Fax Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. Technical Summary This document describes the functional specification and the definition of the ENUM NAPTR record for IFax service. IFax is "Facsimile using Internet Mail". For this use, the DNS returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers, rather than requiring that the sender already know the recipient email address. Working Group Summary This document was reviewed by both the FAX and ENUM working groups. The FAX working group reached consensus on the document, and review by the ENUM working group was requested. Comments provided by the ENUM working group were received and incorporated to produce the document. Protocol Quality Scott Hollenbeck has reviewed the specification for the IESG. _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon, 12 Jul 2004 21:46:07 -0400 From: Richard Shockey Date: Mon, 12 Jul 2004 21:46:07 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-rosenberg-sipping-spam-00.txt Message-ID: <6.1.0.6.2.20040712202027.03a95fd0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO A useful document to review in that some have mis-characterized ENUM as a VoIP spam engine.. X-McAfeeVS-TimeoutProtection: 5 To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Mon, 12 Jul 2004 15:37:09 -0400 Subject: I-D ACTION:draft-rosenberg-sipping-spam-00.txt X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Session Initiation Protocol (SIP) and Spam Author(s) : J. Rosenberg, C. Jennings Filename : draft-rosenberg-sipping-spam-00.txt Pages : 20 Date : 2004-7-12 Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user to user communications. The Session Initiation Protocol (SIP) defines a system for user to user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. Discussions on this draft should be directed at sipping at ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-spam-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sipping-spam-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sipping-spam-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: <2004-7-12143401.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sipping-spam-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Tue, 13 Jul 2004 23:24:18 -0400 From: Richard Shockey Date: Tue, 13 Jul 2004 23:24:18 -0400 To: enum at ietf.org Subject: [Enum] Draft Agenda Items so far for IETF 60 Message-ID: <6.1.0.6.2.20040710163218.03976a28@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO WEDNESDAY, August 4, 2004 1130-1300 Break 1300-1500 Afternoon Sessions I IRTF asrg Anti Spam Working Group OPS capwap Control and Provisioning of Wireless Access Points WG OPS dnsop Domain Name System Operations WG * RTG rpsec Routing Protocol Security Requirements WG SEC krbwg Kerberos WG TSV enum Telephone and Number Mapping WG TSV mmusic Multiparty Multimedia Session Control WG * Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion:enum at ietf.org To Subscribe: enum-request at ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) ( appointment of scribe etc) Ok who wants to volunteer? # 1 Review of the ENUM Operations Document Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-00.txt Pages : 0 Date : 2004-7-12 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-00.txt # 2 Overview of the cost optimization of telecommunication connections based on ENUM as described in the ID "draft-bartosiewicz-enterprise-enum-00.txt". # 3 Disposition of Title : E.164 Number Mapping for the Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-04.txt Pages : 17 Date : 2004-6-8 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-04.txt I'd very much like to come to some conclusion on how this document should progress. IMHO it is an extremely valuable addition to the work effort but it has not had much discussion on the list. Perhaps Experimental. I dont know. As we see deployments progressing the entire issue of provisioning has not IMHO received sufficient attention. #4 ENUM VOID Title : IANA Registration for enumservice void Author(s) : R. Stastny, L. Conroy Filename : draft-stastny-enum-void-00.txt Pages : 7 Date : 2004-7-13 This document registers the 'ENUMservice' 'void' using the URI scheme 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761 [2]. This 'ENUMservice' SHALL be used to indicate that the E.164 number or E.164 number range connected to the domain used in DNS as described in [2] is not assigned to an end-user in case of an E.164 number or to a communication service provider in case of an E.164 number range. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stastny-enum-void-00.txt The on to the Carrier ENUM Mini-BOF A. Introduction to the problem statement ( R. Shockey) B. Title : A Combined User/Carrier ENUM Author(s) : P. Pfautz, S. Lind Filename : draft-pfautz-lind-enum-carrier-00.txt Pages : 5 Date : 2004-7-8 This document considers how so-called "carrier" or "infrastructure" ENUM and "end user" or "public" ENUM can share a single Tier 1 registry yet have independent Tier 2 providers. This approach allows the common cooperative infrastructure required by ENUM to be shared by end users and carriers reducing costs and facilitating adoption of ENUM generally. The essence of the proposal is to populate the Tier 1 registry with non-terminal NAPTRs rather than NS records and use different ENUM service fields for carrier and end user records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-00.txt further details to follow. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Unknown Tue, 13 Jul 2004 23:24:18 -0400 From: Unknown Date: Tue, 13 Jul 2004 23:24:18 -0400 Subject: Message-ID: <165325b15f8a74b819428ec646b783bd@NO-ID-FOUND.mhonarc.org> MIME-Version: 1.0 Content-Type: text/plain Status: RO >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum DT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkYSj-0004Of-Pj for enum at ietf.org; Tue, 13 Jul 2004 21:21:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkYAS-0000jQ-00 for enum at ietf.org; Tue, 13 Jul 2004 21:02:43 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1BkXsf-0004j5-00 for enum at ietf.org; Tue, 13 Jul 2004 20:44:18 -0400 Received: from ibm-eyjgx9r6nqt.shockey.us (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i6E0hll24416 for ; Tue, 13 Jul 2004 17:43:47 -0700 Message-Id: <6.1.0.6.2.20040713203643.03982a30 at joy.songbird.com> X-Sender: richard at joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 13 Jul 2004 20:36:49 -0400 To: enum at ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Subject: [Enum] Fwd: I-D ACTION:draft-stastny-enum-void-00.txt X-BeenThere: enum at ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces at ietf.org Errors-To: enum-bounces at ietf.org >To: i-d-announce at ietf.org >From: Internet-Drafts at ietf.org >Date: Tue, 13 Jul 2004 15:34:41 -0400 >Subject: I-D ACTION:draft-stastny-enum-void-00.txt >X-BeenThere: i-d-announce at ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: internet-drafts at ietf.org >List-Id: i-d-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: i-d-announce-bounces at ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : IANA Registration for enumservice void > Author(s) : R. Stastny, L. Conroy > Filename : draft-stastny-enum-void-00.txt > Pages : 7 > Date : 2004-7-13 > >This document registers the 'ENUMservice' 'void' using the URI > scheme 'mailto:' as per the IANA registration process defined in the > ENUM specification RFC3761 [2]. This 'ENUMservice' SHALL be used to > indicate that the E.164 number or E.164 number range connected to > the domain used in DNS as described in [2] is not assigned to an > end-user in case of an E.164 number or to a communication service > provider in case of an E.164 number range. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-stastny-enum-void-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request at ietf.org with the word unsubscribe in the body of the >message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-stastny-enum-void-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 at ietf.org. >In the body type: > "FILE /internet-drafts/draft-stastny-enum-void-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: <2004-7-13144421.I-D at ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-stastny-enum-void-00.txt > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce at ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Wed, 14 Jul 2004 09:43:59 -0400 From: "Conroy, Lawrence (SMTP)" Date: Wed, 14 Jul 2004 09:43:59 -0400 To: "'enum at ietf.org> Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-experiences-00.txt In-Reply-To: <200407121938.PAA05054@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi folks, Why is it that you click the send button, and THEN see the typos? In the penultimate sentence of the 3rd paragraph of section 3.1 of this fine document there's something that might confuse the confusable. To clarify: "For example, a NAPTR with a "sip" ENUMservice may have a low ORDER field value, and yet is chosen before a NAPTR with an "h323" ENUMservice and a high ORDER value". means: "For example, a NAPTR with a "sip" ENUMservice may have a "losing" ORDER field value, and yet is chosen before a NAPTR with an "h323" ENUMservice and a "winning" ORDER value". It does not mean low as in numerically smaller value and high as numerically larger value. We now return you to your prognostications on Privacy and Golden vs. Silver trees. (on the latter, perhaps (i) we should include "glass tree" to describe a tree that is transparent to most users and (ii) given the level of philosophical discussion, if a tree is invisible, does it make a sound when it crashes?). all the best, Lawrence On 12 Jul 2004, at 20:38, Internet-Drafts at ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-00.txt Pages : 0 Date : 2004-7-12 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Wed, 14 Jul 2004 10:00:09 -0400 From: "Conroy, Lawrence (SMTP)" Date: Wed, 14 Jul 2004 10:00:09 -0400 To: "'enum at ietf.org> Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-experiences-00.txt Message-ID: <27F13E62-D59D-11D8-B5A0-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi again folks, There's always one more... It is becoming obvious that I can't tell up from down. In the recommendations at the end of section 3.1 of the experiences draft, one of the proposals is: "Client - Clients that offer a list of contacts to the end user for their choice MAY present all NAPTRs, not just the ones with the highest currently unprocessed ORDER field value". This should of course be: "Client - Clients that offer a list of contacts to the end user for their choice MAY present all NAPTRs, not just the ones with the lowest currently unprocessed ORDER field value". There are a could of typos that have no real impact ("holding" -> "holds", "single" -> "a single", and finally "SHOULD" -> "and SHOULD"). BTW, I have no idea where the '>' characters before "From Experience" in section 1 and 3.2 appeared. I've checked and they were not in the email that was sent to I-D. Go figure. all the best, Lawrence _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Wed, 14 Jul 2004 19:37:19 -0400 From: Richard Shockey Date: Wed, 14 Jul 2004 19:37:19 -0400 To: enum at ietf.org Subject: [Enum] Fwd: [vpim] I-D ACTION:draft-ietf-vpim-routing-06.txt Message-ID: <6.1.0.6.2.20040714162228.04196e88@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Tue, 13 Jul 2004 16:09:47 -0400 Cc: vpim at ietf.org Subject: [vpim] I-D ACTION:draft-ietf-vpim-routing-06.txt X-BeenThere: vpim at ietf.org X-Mailman-Version: 2.1.5 List-Id: Voice Profile for Internet Mail Discussion Archive List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: vpim-bounces at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Voice Profile for Internet Mail Working Group of the IETF. Title : Voice Message Routing Service Author(s) : G. Vaudreuil Filename : draft-ietf-vpim-routing-06.txt Pages : 11 Date : 2004-7-13 Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The VPIM Directory service provides a directory mechanism to lookup a VPIM email address with a telephone number and confirm that the address is both valid and the associated with the intended recipient. However this service will take time become widely deployed in the nearest term. This document also describes a more limited send-and-pray service useful simply to route and deliver messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilies. Please send comments on this document to the VPIM working group mailing list A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vpim-routing-06.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 at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-vpim-routing-06.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: <2004-7-13145355.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vpim-routing-06.txt _______________________________________________ VPIM mailing list VPIM at ietf.org https://www1.ietf.org/mailman/listinfo/vpim >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From iesg-secretary@ietf.org Thu, 15 Jul 2004 15:30:23 -0400 From: The IESG Date: Thu, 15 Jul 2004 15:30:23 -0400 To: ietf-announce at ietf.org Subject: [Enum] Protocol Action: 'Enumservice Registration for Presence Services' to Proposed Standard Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO The IESG has approved the following document: - 'Enumservice Registration for Presence Services ' as a Proposed Standard This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document registers an ENUM service for presence services (as described in RFC 2778), pursuant to the guidelines in RFC 3761. Specifically, this document focuses on provisioning pres URIs in ENUM. Working Group Summary The working group was very comfortable with adopting this service registration for the standards track and progressing it. Protocol Quality There are not currently implementations of pres: service registrations, as far as can be ascertained. The service registration has been carefully constructed. It was reviewed for the IESG by Allison Mankin. RFC Editor Note: Change the example to be checklist compliant. OLD: $ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. IN NAPTR 100 10 "u" "E2U+pres" "!^.*$!pres:jon.peterson at neustar.biz!" NEW: $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. IN NAPTR 100 10 "u" "E2U+pres" "!^.*$!pres:jon.peterson at example.net!" _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Sun, 18 Jul 2004 23:46:38 -0400 From: James Seng Date: Sun, 18 Jul 2004 23:46:38 -0400 To: enum at ietf.org Subject: [Enum] Formation of APEET Message-ID: <40FB4292.3060404@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: RO Singapore, July 19, 2004 - [CNNIC] (China Network Information Center), [JPRS] (Japan Registry Service), [KRNIC] (Korea Network Information Center), [SGNIC] (Singapore Network Information Center) and [TWNIC] (Taiwan Network Information Center) today announced the formation of Asia Pacific ENUM Engineering Team (APEET), an informal technical project team formed to coordinate and synergize ENUM activities in the Asia Pacific region. The proposal to form APEET was discussed during an ENUM BoF (Birds-of-a-Feather) session at APRICOT (Asia Pacific Regional Internet Conference on Operational Technologies) in February 2004. Founding member organizations of APEET shared a common vision that as a collective group, they will be able to achieve greater community awareness and better interoperability of ENUM-based trials. "ENUM allows IP devices to be assigned a telephone number which is globally interoperable," says James Seng, Chairman of APEET. "It is a key enabling technology for seamless IP Telephony which will greatly benefit the end-users." Before the formation of APEET, each member organization has been conducting its own ENUM trials, most of which are isolated trials conducted within each member organizationâs country/region. With the formation of APEET, member organizations will be able to implement technical solutions that facilitate ENUM trials across Asia Pacific. "We are extremely excited about the formation of this much needed organization," says Hiro Hotta, Director JPRS. "We are ready to bring ENUM trials to the next level." One of APEET's key project is to implement a live ENUM trial at APRICOT 2005, Kyoto, Japan. The live trial will allow hundreds of APRICOT participants to experience IP Telephony using wireless SIP Phones and calling each another with standard 10-key telephone interface via ENUM. The live trial, believed to be the first of its kind, will serve to demonstrate and educate the technical community on the power, capabilities and feasibility of ENUM together with SIP. "This looks like one of the most exciting events of 2005 with a demonstration of technologies to rock Asia Pacific", says Richard Shockey, co-Chair of Internet Engineering Task Force (IETF) ENUM Working Group. The formation of APEET has been well received by the Industry. (APNIC) Asia Pacific Network Information Center has extended its goodwill to host DNS records of "apenum.org" â the selected "golden root" of APEET technical trials. APEET is also fortunate to have individual experts member such as Richard Shockey. APEET welcomes all Asia Pacific ccTLD administrators (or its designated representatives) to join and contribute towards the success of ENUM adoption in Asia Pacific. For more information, please visit http://www.apenum.org Media Contact: James Seng jseng at pobox.org.sg _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Mon, 19 Jul 2004 01:04:52 -0400 From: "Peter Williams" Date: Mon, 19 Jul 2004 01:04:52 -0400 To: enum at ietf.org Subject: RE: [Enum] Formation of APEET Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO "The formation of APEET has been well received by the Industry. (APNIC) Asia Pacific Network Information Center has extended its goodwill to host DNS records of "apenum.org" â?? the selected "golden root" of APEET technical trials. APEET is also fortunate to have individual experts member such as Richard Shockey. ; Could the experts define "golden root", in terms of that IETF members might understand? From: James Seng To: enum at ietf.org Subject: [Enum] Formation of APEET Date: Mon, 19 Jul 2004 11:40:02 +0800 Singapore, July 19, 2004 - [CNNIC] (China Network Information Center), [JPRS] (Japan Registry Service), [KRNIC] (Korea Network Information Center), [SGNIC] (Singapore Network Information Center) and [TWNIC] (Taiwan Network Information Center) today announced the formation of Asia Pacific ENUM Engineering Team (APEET), an informal technical project team formed to coordinate and synergize ENUM activities in the Asia Pacific region. The proposal to form APEET was discussed during an ENUM BoF (Birds-of-a-Feather) session at APRICOT (Asia Pacific Regional Internet Conference on Operational Technologies) in February 2004. Founding member organizations of APEET shared a common vision that as a collective group, they will be able to achieve greater community awareness and better interoperability of ENUM-based trials. "ENUM allows IP devices to be assigned a telephone number which is globally interoperable," says James Seng, Chairman of APEET. "It is a key enabling technology for seamless IP Telephony which will greatly benefit the end-users." Before the formation of APEET, each member organization has been conducting its own ENUM trials, most of which are isolated trials conducted within each member organizationâ??s country/region. With the formation of APEET, member organizations will be able to implement technical solutions that facilitate ENUM trials across Asia Pacific. "We are extremely excited about the formation of this much needed organization," says Hiro Hotta, Director JPRS. "We are ready to bring ENUM trials to the next level." One of APEET's key project is to implement a live ENUM trial at APRICOT 2005, Kyoto, Japan. The live trial will allow hundreds of APRICOT participants to experience IP Telephony using wireless SIP Phones and calling each another with standard 10-key telephone interface via ENUM. The live trial, believed to be the first of its kind, will serve to demonstrate and educate the technical community on the power, capabilities and feasibility of ENUM together with SIP. "This looks like one of the most exciting events of 2005 with a demonstration of technologies to rock Asia Pacific", says Richard Shockey, co-Chair of Internet Engineering Task Force (IETF) ENUM Working Group. The formation of APEET has been well received by the Industry. (APNIC) Asia Pacific Network Information Center has extended its goodwill to host DNS records of "apenum.org" â?? the selected "golden root" of APEET technical trials. APEET is also fortunate to have individual experts member such as Richard Shockey. APEET welcomes all Asia Pacific ccTLD administrators (or its designated representatives) to join and contribute towards the success of ENUM adoption in Asia Pacific. For more information, please visit http://www.apenum.org Media Contact: James Seng jseng at pobox.org.sg _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Mon, 19 Jul 2004 13:41:40 -0400 From: "Conroy, Lawrence (SMTP)" Date: Mon, 19 Jul 2004 13:41:40 -0400 To: "'enum at ietf.org> Subject: [Enum] (no subject) Message-ID: <47342B00-D9A9-11D8-8576-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Richard, Scott, folks, I note that we still haven't really processed the EPP-E164 draft, so here's my attempt to re-start this. First, as I understand it, it's an XML (sub-)schema that operates within a pure client-server model, so in terms of a protocol, it works if it's a valid schema and fits to the guidelines in RFC3735. I am not now, nor have I ever been, knowingly a member of any cults; I'm not for or against any protocol on religious principle. Thus the following is for my clarification only. I have a couple of questions on the draft content. I'm no XML expert, so these may be dumb but... (i) 2.2.4 (and the xml schema in 4) gives the service field a max length of 65 characters. This seems perfectly reasonable to me, but why 65 as opposed to 60 or 70? (ii) 2.2.6 (and the xml schema in 4) gives the replacement field a max length of 255 characters. Again, this seems overkill if anything, as the max domain name is less than this, I thought. Thus why so long - is this a SNAPTR requirement? (iii) (a) 3.1.2 items 3..6. Aren't these conditionally mandatory, rather than purely optional? (This is also true for 3.2.1 and 3.2.5, except that in those cases it's the client specifying the content, not the server) (b) From the schema in 4, it seems that these child elements cannot be empty - am I right in this? Finally, I'm trying to understand the use of this protocol/extension, as it is not obvious to me that populating NAPTRs in a zone is the sort of thing I'd expect a Registrar (or a Registrant) to request be done to a central repository. Thus, a pair of questions: (iv) Under what circumstances would someone use a Registrar-Registry Protocol to populate NAPTRs in a zone, and who is that "someone"? (v) Is this extension intended *only* for central Registry zone population (i.e. non-delegated zones)? all the best, Lawrence _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shollenbeck@verisign.com Mon, 19 Jul 2004 14:14:22 -0400 From: "Hollenbeck, Scott" Date: Mon, 19 Jul 2004 14:14:22 -0400 To: "'Conroy, Lawrence (SMTP)'" Subject: [Enum] RE: EPP-E164 Questions Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF03BD20B0@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO (adding a subject...) Thanks for the note, Lawrence. It's nice to see someone else reading the document! Responses below. -Scott- > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc at roke.co.uk] > Sent: Monday, July 19, 2004 1:30 PM > To: 'enum at ietf.org' > Cc: Richard Shockey; Scott Hollenbeck > Subject: [snip] > (i) 2.2.4 (and the xml schema in 4) gives the service field a max > length of 65 characters. > This seems perfectly reasonable to me, but why 65 as > opposed to > 60 or 70? This makes more sense if you start by looking at RFC 2915 instead of RFC 3403. The ABNF in 2915 indicates a maximum length for the service field of 65 characters. 3403 now says that "It is up to the Application Specification to specify the values found in this field". So, the sort answer is that the length limit has been there since 2915. It may or may not be appropriate now -- I'm open to removing the upper limit if that lines up better with 3403. > (ii) 2.2.6 (and the xml schema in 4) gives the replacement field a > max length of > 255 characters. Again, this seems overkill if > anything, as the > max domain name > is less than this, I thought. Thus why so long - is this a > SNAPTR requirement? This limit is arbitrary. It was selected as a guess at what might be "long enough". When doing the EPP work in provreg several implementers asked for upper length limits on string fields to help make their coding lives easier. This is just an artifact of a general approach I took with EPP to accommodate such requests. > (iii) (a) 3.1.2 items 3..6. Aren't these conditionally mandatory, > rather than > purely optional? (This is also true for 3.2.1 and 3.2.5, > except that > in those cases it's the client specifying the > content, not > the server) IIRC 2915/3403 notes that these fields might be empty in some cases. At least I remember Michael Mealling telling me that they might be empty! From a purely mechanical schema perspective, there's thus no way of applying policy to know if they need to be there or not. They're OPTIONAL because they may or may not be there depending on other factors. Some other specification that defines a policy will have to determine if/when these elements will need to be there. > (b) From the schema in 4, it seems that these child elements > cannot be empty > - am I right in this? That's correct. They can be left out, but if they're present they can't be empty. > Finally, I'm trying to understand the use of this protocol/extension, > as it is not obvious to me > that populating NAPTRs in a zone is the sort of thing I'd expect a > Registrar (or a Registrant) > to request be done to a central repository. Thus, a pair of questions: > > (iv) Under what circumstances would someone use a Registrar-Registry > Protocol to populate NAPTRs in a zone, and who is that > "someone"? I think that's TBD, and a matter of implementation policy. As I mentioned in an earlier exchange with Michael Haberling it may or may not be appropriate in all operating environments, but the capability will exist for those environments where it's deemed useful. The US ENUM Forum, for example, has expressed an interest in the idea. > (v) Is this extension intended *only* for central Registry zone > population (i.e. non-delegated > zones)? It can be used anywhere EPP is or might be deployed. Admittedly that's currently only by TLD zone administrators and the entities that interact with them, but there's nothing in the protocol itself to impose that kind of limitation. -Scott- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Jason_Livingood@cable.comcast.com Thu, 22 Jul 2004 11:38:52 -0400 From: "Livingood, Jason" Date: Thu, 22 Jul 2004 11:38:52 -0400 To: ppfautz at att.com> Subject: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Message Status: RO Thanks to Penn and Steve for submitting this draft!  It appears to present a workable technical solution to the discussions we've been having on infrastructure vs. end user ENUM (putting privacy concerns aside for a moment).   I have minor comments / suggestions that may make this draft more usable in practice, and more acceptable to a wider audience.  This involves a modification of the class of service acronyms.    The draft proposes two class of service acronyms: 1.  E2U - ENUM to URI, for End User records. 2.  E2C - ENUM to Carrier, for Carrier or Service Provider records   Which look like this, as cited in the draft:     $Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa.        IN NAPTR 100 50 "" "E2U"   "" 9.0.3.5.7.6.8.7.9.4.1.joesenum.com        IN NAPTR 100 50 "" "E2C"   "" 9.0.3.5.7.6.8.7.9.4.1.telco.net   I submit that in the practice of manually provisioning records in the DNS, in troubleshooting, or in general human use and reading of DNS records or query results, that "E2U" and "E2C" are simply to similar to one another visually.  I think that in practice this could cause unnecessary difficulty and confusion.  I would recommend that a different acronym be chosen for infrastructure uses that is unmistakably different from "E2U."  This would pay heed to the human factors that will be present when dealing with a large number of these records day in and day out.   The second concern is around the word "Carrier" and therefore the "C" portion of the class of service acronym.  I believe that carrier is a rather limited description of the entities which may have networks and services associated with this class of service.  I would suggest instead something focused on "service providers."   For these two reasons, I think that the draft should modify the seconds acronym from "E2C" to something else, perhaps "SPR" (Service Provider Record) or "SPU" (Service Provider URI).   Respectfully submitted, Jason   Jason Livingood Director - Forward Looking Communication Services Communications Services Engineering Comcast Cable Communications 215-981-7813 jason_livingood at cable.comcast.com   _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 22 Jul 2004 19:06:34 -0400 From: Richard Shockey Date: Thu, 22 Jul 2004 19:06:34 -0400 To: enum at ietf.org Subject: [Enum] Last Call Agenda ENUM WG IETF 60 Message-ID: <6.1.0.6.2.20040720164528.044a7ec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Last Call ... there will be an additional Agenda for the BOF shortly. WEDNESDAY, August 4, 2004 1130-1300 Break 1300-1500 Afternoon Sessions I IRTF asrg Anti Spam Working Group OPS capwap Control and Provisioning of Wireless Access Points WG OPS dnsop Domain Name System Operations WG * RTG rpsec Routing Protocol Security Requirements WG SEC krbwg Kerberos WG TSV enum Telephone and Number Mapping WG TSV mmusic Multiparty Multimedia Session Control WG * Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion:enum at ietf.org To Subscribe: enum-request at ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) ( appointment of scribe etc) Ok who wants to volunteer? # 1 Review of the ENUM Operations Document [ 10 Min] Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-00.txt Pages : 0 Date : 2004-7-12 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-00.txt # 2 Overview of the cost optimization of telecommunication connections based on ENUM as described in the ID "draft-bartosiewicz-enterprise-enum-00.txt".[ 10 Min] # 3 Disposition of [ 10 Min] Title : E.164 Number Mapping for the Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-04.txt Pages : 17 Date : 2004-6-8 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-04.txt I'd very much like to come to some conclusion on how this document should progress. IMHO it is an extremely valuable addition to the work effort but it has not had much discussion on the list. Perhaps Experimental. I dont know. As we see deployments progressing the entire issue of provisioning has not IMHO received sufficient attention. #4 ENUM VOID [ 10 Min] Title : IANA Registration for enumservice void Author(s) : R. Stastny, L. Conroy Filename : draft-stastny-enum-void-00.txt Pages : 7 Date : 2004-7-13 This document registers the 'ENUMservice' 'void' using the URI scheme 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761 [2]. This 'ENUMservice' SHALL be used to indicate that the E.164 number or E.164 number range connected to the domain used in DNS as described in [2] is not assigned to an end-user in case of an E.164 number or to a communication service provider in case of an E.164 number range. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stastny-enum-void-00.txt The on to the Carrier ENUM Mini-BOF [ 1 hour ] A. Introduction to the problem statement ( R. Shockey) This discussion will focus only on Requirements and not on specific solutions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Fri, 23 Jul 2004 04:18:28 -0400 From: "Peter Williams" Date: Fri, 23 Jul 2004 04:18:28 -0400 To: Richard.Stastny at oefeg.at Subject: Re: [Enum] IETF, ENUM and NGN Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO > > I have an account at the University of Vienna IP PBX > which is connected via Telekom Austria in Vienna > +43 1 59966 366027 > but the number is also a private network number assigned > +43 59966 366027 > Both entries are in ENUM and pointing to > sip:e001-366027 at enum.at43.at > (BTW this is an example of privacy) How is this an example of privacy??? Given the whole internet knows that these phone numers are personal identificiation material, providers are NOW responsible for protecting the expectations of EU persons, NOW. If their policies have rules concerning semi-public persons (like most of us, who use publicity to establish professional reputation ), the provider may be able to escape certain obligations - IF their own rules disclaim such obligations. Who is the ENUM provider, TODAY? I need a legal name, so I can refer the data protection authorities to the abuser (if any abuse is occuring). Lets view the data protection and privacy policies, for educational purposes, and see what protections they represent they provide. We need to view similar policies of the delegation authority, as their unilateral acions can cause servers and authorities handling a given name to change. This implies that yhe policies setting the exectation for a given name can change - without notice to the party relying on the earlier disclosure. (No: you cannot expect grandmother to pull up her dns tool , and parse the ENUM syntax, wherein the revised notice string is located, in Arabic script) _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Fri, 23 Jul 2004 10:07:36 -0400 From: "Conroy, Lawrence (SMTP)" Date: Fri, 23 Jul 2004 10:07:36 -0400 To: "'enum at ietf.org> Subject: [Enum] FYI - New version of the VOVI draft Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Folks, You may note that there's a new version of VOVI (draft-brandner-vovi-02.txt) in the I-D store - see: . In short, this has removed all but the voice:tel and video:tel specifications, so we hope that it is non-contentious. The ENUMservice "voice:tel" is currently present in a number of zones, and is supported in a number of implemented clients. Given that there's only one hour for the main ENUM meeting, could folks please look at this *before* the meeting and preferably make comments on-list ASAP? all the best, Lawrence _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 23 Jul 2004 14:08:20 -0400 From: Richard Shockey Date: Fri, 23 Jul 2004 14:08:20 -0400 To: enum at ietf.org Subject: [Enum] Documents related to the Administration of e164.apra Message-ID: <6.1.0.6.2.20040714170500.03d70d30@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO FYI as it relates the MINI-BOF discussion. [RFC3026] Blaine, R. "Liaison to IETF/ISOC on ENUM" RFC 3026, January 2001 http://www.ietf.org/rfc/rfc3026.txt [RFC 3245] Klensin, J. Editor "The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)" RFC 3245, http://www.ietf.org/rfc/rfc3245.txt March 2002 Interim Procedures for the delegation of E.164 Shared Country Codes for Networks and Groups of Countries; http://www.itu.int/ITU-T/inr/enum/procedures.html http://www.itu.int/ITU-T/inr/enum/procedures-02.html SOURCE: Internet Architecture Board (IAB), ISOC TITLE: Re. ENUM LIAISON ON IAB INSTRUCTIONS TO RIPE-NCC http://www.iab.org/documents/docs/sg2-liaison-e164-sep-02.html TITLE: Administrative aspects of ENUM - Security LIAISON STATEMENT TO: ITU-T SG2 http://www.iab.org/documents/docs/sg2-liaisonb-feb-03.html SOURCE: Internet Architecture Board (IAB), ISOC TITLE: Re. e164.arpa domain management LIAISON STATEMENT TO: ITU- T SG2 http://www.iab.org/documents/docs/sg2-liaisona-feb-03.html IAB Press Statement on ENUM http://www.iab.org/documents/docs/enum-pr.html ITU-T SG2 Response to Liaison Statement re ENUM http://www.iab.org/documents/docs/itu.pdf IAB Liaison to IT SG2 TITLE: Reflections on risks of, and barriers to, ENUM deployment http://www.iab.org/documents/docs/iab-sg2-liaison-3.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 23 Jul 2004 14:08:20 -0400 From: "Stastny Richard" Date: Fri, 23 Jul 2004 14:08:20 -0400 To: "Livingood, Jason" Subject: Re: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" Message-ID: <06CF906FE3998C4E944213062009F1624437FC@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO I think before we get into technical discussions, e.g. how this fits with the DDDS algorithm and if it is wise to need always at least two ENUM queries to get an answer, we should try to find out if this solution really is what is required, if this solution in managable, etc. And last but not least, somebody needs to explain ITU-T and the national regulators (NRAs) that c.c.e164.arpa is not longer a national opt-in decision, because I as a carrier now have the RIGHT to have a delegation of my numbers in e164.arpa. nice try ;-) Richard -----UrsprÃngliche Nachricht----- Von: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] Gesendet: Do 22.07.2004 17:28 An: enum at ietf.org; 'sdlind at att.com'; 'ppfautz at att.com' Cc: Betreff: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" Thanks to Penn and Steve for submitting this draft! It appears to present a workable technical solution to the discussions we've been having on infrastructure vs. end user ENUM (putting privacy concerns aside for a moment). I have minor comments / suggestions that may make this draft more usable in practice, and more acceptable to a wider audience. This involves a modification of the class of service acronyms. The draft proposes two class of service acronyms: 1. E2U - ENUM to URI, for End User records. 2. E2C - ENUM to Carrier, for Carrier or Service Provider records Which look like this, as cited in the draft: $Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa. IN NAPTR 100 50 "" "E2U" "" 9.0.3.5.7.6.8.7.9.4.1.joesenum.com IN NAPTR 100 50 "" "E2C" "" 9.0.3.5.7.6.8.7.9.4.1.telco.net I submit that in the practice of manually provisioning records in the DNS, in troubleshooting, or in general human use and reading of DNS records or query results, that "E2U" and "E2C" are simply to similar to one another visually. I think that in practice this could cause unnecessary difficulty and confusion. I would recommend that a different acronym be chosen for infrastructure uses that is unmistakably different from "E2U." This would pay heed to the human factors that will be present when dealing with a large number of these records day in and day out. The second concern is around the word "Carrier" and therefore the "C" portion of the class of service acronym. I believe that carrier is a rather limited description of the entities which may have networks and services associated with this class of service. I would suggest instead something focused on "service providers." For these two reasons, I think that the draft should modify the seconds acronym from "E2C" to something else, perhaps "SPR" (Service Provider Record) or "SPU" (Service Provider URI). Respectfully submitted, Jason Jason Livingood Director - Forward Looking Communication Services Communications Services Engineering Comcast Cable Communications 215-981-7813 jason_livingood at cable.comcast.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 23 Jul 2004 14:38:08 -0400 From: Richard Shockey Date: Fri, 23 Jul 2004 14:38:08 -0400 To: "Stastny Richard" Subject: Re: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" In-Reply-To: <06CF906FE3998C4E944213062009F1624437FC@oefeg-s02.oefeg.loc> Message-ID: <6.1.0.6.2.20040723142611.03f81ca0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 02:06 PM 7/23/2004, Stastny Richard wrote: Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" I think before we get into technical discussions, e.g. how this fits with the DDDS algorithm and if it is wise to need always at least two ENUM queries to get an answer, we should try to find out if this solution really is what is required, if this solution in managable, etc. And last but not least, somebody needs to explain ITU-T and the national regulators (NRAs) that c.c.e164.arpa is not longer a national opt-in decision, because I as a carrier now have the RIGHT to have a delegation of my numbers in e164.arp Given that the administrative policies and procedures regarding the various trees of e164.arpa are by IAB/ITU definition nation state matters I continue to find it baffling that service providers would want to put the administrative, policies and procedures surrounding their internal routing data within the grasp of their (NRA's) regulators. What are you all thinking? nice try ;-) Richard >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 23 Jul 2004 15:12:12 -0400 From: Jim Reid Date: Fri, 23 Jul 2004 15:12:12 -0400 To: Richard Shockey Subject: Re: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" In-Reply-To: <6.1.0.6.2.20040723142611.03f81ca0@joy.songbird.com> Message-ID: <5344.1090609745@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO >>>>> "Richard" == Richard Shockey writes: Richard> Given that the administrative policies and procedures Richard> regarding the various trees of e164.arpa are by IAB/ITU Richard> definition nation state matters I continue to find it Richard> baffling that service providers would want to put the Richard> administrative, policies and procedures surrounding their Richard> internal routing data within the grasp of their (NRA's) Richard> regulators. Richard> What are you all thinking? I'm with you. IMO, the trees for User and Infrastructure/Operator ENUM must be mutually exclusive. They serve different purposes and have mutually exclusive contraints on subjects like data protection, privacy, authentication, verification, opt-in/out, regulatory considerations, etc, etc. For example if I have an unlisted number, it more than likely shouldn't be in the public (User) ENUM tree. But if my provider is doing VoIP, my number will need to be in their private Operator tree so their call routing stuff can find the appropriate SIP gateway or whatever for my number. I also find it curiously refreshing that an operator would choose to expose its customer data and routing info to competitors. Or the general public. Which this draft seems to be promoting. Maybe I'm missing something? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Fri, 23 Jul 2004 16:59:21 -0400 From: "Pfautz, Penn L, ALABS" Date: Fri, 23 Jul 2004 16:59:21 -0400 To: "Stastny Richard" Subject: RE: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" Message-ID: <34DA635B184A644DA4588E260EC0A25A07BA1530@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Richard: Status: RO The basic problem I'm trying to address is how the use of ENUM for carrier interconnection can coexist with its use by end users, the latter of which I take as a given based on what has transpired in the IETF and ITU. If end user choice is a possibility, then there are issues with what to do if the end user wishes to register something other than a the carrier info and vice versa. I don't believe this always requires two queries, and, in fact, that's what I'm trying to avoid. An entity quering the proposed combined Tier 1 COULD get two NAPTRS back but might only get one. Even when two are returned, the calling party could choose to follow just one path, i.e. to prefer the end user or prefer the carrier path. If carrier ENUM is in a separate tree then I have to do two queries to determine that there is a record in neither versus one under my proposal. Finally, I don't think my proposal in any way implies that carriers have a right to ENUM records absent a national opt-in decision. In fact, by proposing a common Tier 1 rooted in cc.e164.arpa I pretty much make carrier ENUM depend on national opt-in to ENUM. Penn -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Stastny Richard Sent: Friday, July 23, 2004 2:06 PM To: Livingood, Jason; enum at ietf.org; Lind, Steven D, ALABS; Pfautz, Penn L, ALABS Subject: Re: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" I think before we get into technical discussions, e.g. how this fits with the DDDS algorithm and if it is wise to need always at least two ENUM queries to get an answer, we should try to find out if this solution really is what is required, if this solution in managable, etc. And last but not least, somebody needs to explain ITU-T and the national regulators (NRAs) that c.c.e164.arpa is not longer a national opt-in decision, because I as a carrier now have the RIGHT to have a delegation of my numbers in e164.arpa. nice try ;-) Richard -----UrsprÃngliche Nachricht----- Von: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] Gesendet: Do 22.07.2004 17:28 An: enum at ietf.org; 'sdlind at att.com'; 'ppfautz at att.com' Cc: Betreff: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" Thanks to Penn and Steve for submitting this draft! It appears to present a workable technical solution to the discussions we've been having on infrastructure vs. end user ENUM (putting privacy concerns aside for a moment). I have minor comments / suggestions that may make this draft more usable in practice, and more acceptable to a wider audience. This involves a modification of the class of service acronyms. The draft proposes two class of service acronyms: 1. E2U - ENUM to URI, for End User records. 2. E2C - ENUM to Carrier, for Carrier or Service Provider records Which look like this, as cited in the draft: $Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa. IN NAPTR 100 50 "" "E2U" "" 9.0.3.5.7.6.8.7.9.4.1.joesenum.com IN NAPTR 100 50 "" "E2C" "" 9.0.3.5.7.6.8.7.9.4.1.telco.net I submit that in the practice of manually provisioning records in the DNS, in troubleshooting, or in general human use and reading of DNS records or query results, that "E2U" and "E2C" are simply to similar to one another visually. I think that in practice this could cause unnecessary difficulty and confusion. I would recommend that a different acronym be chosen for infrastructure uses that is unmistakably different from "E2U." This would pay heed to the human factors that will be present when dealing with a large number of these records day in and day out. The second concern is around the word "Carrier" and therefore the "C" portion of the class of service acronym. I believe that carrier is a rather limited description of the entities which may have networks and services associated with this class of service. I would suggest instead something focused on "service providers." For these two reasons, I think that the draft should modify the seconds acronym from "E2C" to something else, perhaps "SPR" (Service Provider Record) or "SPU" (Service Provider URI). Respectfully submitted, Jason Jason Livingood Director - Forward Looking Communication Services Communications Services Engineering Comcast Cable Communications 215-981-7813 jason_livingood at cable.comcast.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Fri, 23 Jul 2004 20:14:25 -0400 From: "Pfautz, Penn L, ALABS" Date: Fri, 23 Jul 2004 20:14:25 -0400 To: "Jim Reid" Subject: RE: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" Message-ID: <34DA635B184A644DA4588E260EC0A25A07BA16D5@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO A clarification - we need to distinguish between a carrier's internal routing data and a specification of points of interface. While carriers might and could decide to put the final route to the end user terminal in the public DNS, they might also just put in a border element address. This allows others to deliver calls to the carrier for ulimate delivery to an end user while maintaining some protections. (Indeed such protections may be one of the things voice carriers -as potentially distinct from underlying ISPs- have to offer as value added - but that's another story). And because a carrier could put such border element addresses in ENUM and can put all the numbers in ranges assigned to them (except ported out numbers), it's not so much of a problem if an unlisted number is there, because it's not correlated to a specific end user identity. Even numbers that are currently vacant may be there. But the point of this draft *is* to expose some kind of routing to outside parties. I want them to be able to reach my customers in the IP plane and I want, in turn, to reach theirs that way. The private possibilties of the protocol defined in RFC 2916 have been recognized from the start, but If carrier ENUM is something just between consenting service providers in an equipment closet, then, it's a whole lot less interesting to me. Penn -----Original Message----- From: Jim Reid [mailto:jim at rfc1035.com] Sent: Friday, July 23, 2004 3:09 PM To: Richard Shockey Cc: Richard Stastny; enum at ietf.org; Lind, Steven D, ALABS; Pfautz, Penn L, ALABS Subject: Re: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" >>>>> "Richard" == Richard Shockey writes: Richard> Given that the administrative policies and procedures Richard> regarding the various trees of e164.arpa are by IAB/ITU Richard> definition nation state matters I continue to find it Richard> baffling that service providers would want to put the Richard> administrative, policies and procedures surrounding their Richard> internal routing data within the grasp of their (NRA's) Richard> regulators. Richard> What are you all thinking? I'm with you. IMO, the trees for User and Infrastructure/Operator ENUM must be mutually exclusive. They serve different purposes and have mutually exclusive contraints on subjects like data protection, privacy, authentication, verification, opt-in/out, regulatory considerations, etc, etc. For example if I have an unlisted number, it more than likely shouldn't be in the public (User) ENUM tree. But if my provider is doing VoIP, my number will need to be in their private Operator tree so their call routing stuff can find the appropriate SIP gateway or whatever for my number. I also find it curiously refreshing that an operator would choose to expose its customer data and routing info to competitors. Or the general public. Which this draft seems to be promoting. Maybe I'm missing something? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rfearing@ix.netcom.com Fri, 23 Jul 2004 21:34:59 -0400 From: Roger Fearing Date: Fri, 23 Jul 2004 21:34:59 -0400 To: "Pfautz, Penn L, ALABS" Subject: RE: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" In-Reply-To: <34DA635B184A644DA4588E260EC0A25A07BA16D5@ACCLUST02EVS1.ugd .att.com> Message-ID: <5.2.1.1.2.20040723181007.0338a0e0@pop.ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Ives, Ray, I think they are beginning to get it...if I am reading them right... See; "This allows others to deliver calls to the carrier for ulimate delivery to an end user while maintaining some protections. (Indeed such protections may be one of the things voice carriers -as potentially distinct from underlying ISPs- have to offer as value added - but that's another story)." Sincerely, Roger At 08:04 PM 7/23/04 -0400, Pfautz, Penn L, ALABS wrote: A clarification - we need to distinguish between a carrier's internal routing data and a specification of points of interface. While carriers might and could decide to put the final route to the end user terminal in the public DNS, they might also just put in a border element address. This allows others to deliver calls to the carrier for ulimate delivery to an end user while maintaining some protections. (Indeed such protections may be one of the things voice carriers -as potentially distinct from underlying ISPs- have to offer as value added - but that's another story). And because a carrier could put such border element addresses in ENUM and can put all the numbers in ranges assigned to them (except ported out numbers), it's not so much of a problem if an unlisted number is there, because it's not correlated to a specific end user identity. Even numbers that are currently vacant may be there. But the point of this draft *is* to expose some kind of routing to outside parties. I want them to be able to reach my customers in the IP plane and I want, in turn, to reach theirs that way. The private possibilties of the protocol defined in RFC 2916 have been recognized from the start, but If carrier ENUM is something just between consenting service providers in an equipment closet, then, it's a whole lot less interesting to me. Penn -----Original Message----- From: Jim Reid [mailto:jim at rfc1035.com] Sent: Friday, July 23, 2004 3:09 PM To: Richard Shockey Cc: Richard Stastny; enum at ietf.org; Lind, Steven D, ALABS; Pfautz, Penn L, ALABS Subject: Re: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" >>>>> "Richard" == Richard Shockey writes: Richard> Given that the administrative policies and procedures Richard> regarding the various trees of e164.arpa are by IAB/ITU Richard> definition nation state matters I continue to find it Richard> baffling that service providers would want to put the Richard> administrative, policies and procedures surrounding their Richard> internal routing data within the grasp of their (NRA's) Richard> regulators. Richard> What are you all thinking? I'm with you. IMO, the trees for User and Infrastructure/Operator ENUM must be mutually exclusive. They serve different purposes and have mutually exclusive contraints on subjects like data protection, privacy, authentication, verification, opt-in/out, regulatory considerations, etc, etc. For example if I have an unlisted number, it more than likely shouldn't be in the public (User) ENUM tree. But if my provider is doing VoIP, my number will need to be in their private Operator tree so their call routing stuff can find the appropriate SIP gateway or whatever for my number. I also find it curiously refreshing that an operator would choose to expose its customer data and routing info to competitors. Or the general public. Which this draft seems to be promoting. Maybe I'm missing something? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.725 / Virus Database: 480 - Release Date: 7/19/04 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.725 / Virus Database: 480 - Release Date: 7/19/04 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Sat, 24 Jul 2004 02:17:09 -0400 From: Jeff Williams Date: Sat, 24 Jul 2004 02:17:09 -0400 To: Richard Shockey Subject: Re: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" In-Reply-To: <06CF906FE3998C4E944213062009F1624437FC@oefeg-s02.oefeg.loc> Message-ID: <410216B4.92604AF6@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Richard and all, Richard Shockey wrote: > At 02:06 PM 7/23/2004, Stastny Richard wrote: > > >Content-Class: urn:content-classes:message > >Content-Type: text/plain; > > charset="utf-8" > > > >I think before we get into technical discussions, e.g. how this fits with > >the DDDS algorithm and > >if it is wise to need always at least two ENUM queries to get an answer, > >we should try to find > >out if this solution really is what is required, if this solution in > >managable, etc. > > > >And last but not least, somebody needs to explain ITU-T and the national > >regulators (NRAs) > >that c.c.e164.arpa is not longer a national opt-in decision, because I as > >a carrier now have > >the RIGHT to have a delegation of my numbers in e164.arp > > Given that the administrative policies and procedures regarding the various > trees of e164.arpa are by IAB/ITU definition nation state matters I > continue to find it baffling that service providers would want to put the > administrative, policies and procedures surrounding their internal routing > data within the grasp of their (NRA's) regulators. > > What are you all thinking? It is baffling to me that you could pose such a question. The answer is simple, that the technical IT community obviously does not wish to listen to the stakeholders/users they directly or indirectly serve, especially with respect to security and privacy laws. The IAB/ITU seems to not be represented adequately by the stakeholders/users or consumers of use of technology's of all types. Hence nations and regions, such as the EU, have seen fit naturally that NRA regulators with the respective national government oversight, are necessary in order the adequately protect their stakeholders/users/citizens. > > > > > >nice try ;-) > > > >Richard > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Sat, 24 Jul 2004 13:00:55 -0400 From: "Peter Williams" Date: Sat, 24 Jul 2004 13:00:55 -0400 To: jim at rfc1035.com Subject: Re: [Enum] new I-D on carrier ENUM Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO The best motivation for infrastructure enum ( in private trees) Ive heared to date is that it enables the provider to satisfy the pending wiretap rules for VoIP - using established practice for assuring governments of accuracy and reliability (and equipment companies get to sell carrier-grade voIP switches and provisioning/wiretap-capable systems). Not only is the reliability of the address of records problem contained within the provider's system and control, but the called party's providers record's accuracy can be similarly assured from the calling provider's perpective, when the infrastructure ENUM manages its own inter-provider naming tree links. Carriers will arrange interconnects only with parties with whom they have the required wiretap agreements and technical arrangements. (This is FBI wiretapping rules, note, not trunk spying by NSA, etc al.) If the relability of the inter-provider knowledge links are managed by a third party - e.g. the public DNS, the provider can be punished for factors beyond the providers control. Ah, the entire population of iraq is suddently unreachable and their critical infrastructure stops working - becuase of a domain name dispute happening in a foreign court. Imagine the mess a third party could make to the wiretap arrangements, if such arrangements require accuracy in DNS records handled by third parties! My understanding of the corporate business thinking about ENUM is that the 2 main ENUM TTPs want the telcos to outsource such DNS management - and thus pushing goverments for wiretap regulation , AND a regime of carrier sanctions - getting governments to create outsourcing markets for the assurance providers, essentially. This works well with the DARPA program for critical infrastructure generation, headed by .arpa. The FBI controls the telco via business regulation, and the DARPA controls the technical providers via IAB/ICANN. Im not sure where Vint stands, however: he stood on the political fence when these same issues were thrashing (between the very same agencies!) in the CA/certs world. We got an internet solution there, Im not sure what will happen with ENUM: telcos had the gumption to standup to the powers over mandatory key escrow then: Im not sure they have the will, this time, to even politic in their own business interests. May be cheaper to just outsource provisioning and name space management to the wiretap/escrow-capable TTPs. From: Jim Reid To: Michael Haberler CC: enum at ietf.org, "Pfautz, Penn L, ALABS" Subject: Re: [Enum] new I-D on carrier ENUM Date: Sat, 10 Jul 2004 19:35:47 +0100 >>>>> "Michael" == Michael Haberler writes: Michael> It seems to me the main reason why ITSP's are pushing for Michael> a *non* e164.arpa tree solution is that with the current Michael> thinking behind user ENUM, namely user opt-in, and in Michael> particular beforehand government opt-in will result in an Michael> extremely slow overall adoption curve, and consequently Michael> ridiculously low resolution rates for a long time to Michael> come. Your perception may be right. But the rationale for a non e164.arpa solution is wrong IMO. A domain name should not be confused with an instantiaton of its name space on the public internet. It seems that some people on this list are unaware of that distinction or are choosing to ignore it. ITSPs -- whatever they are -- can perfectly set up their own private instances of e164.arpa today and populate that with whatever they want however they like. Provided that private tree isn't visible on the internet and doesn't get confused with the public e164.arpa tree, there's no problem. We're done. These ITSPs can just do it. They don't have to ask anyone's permission. Or get a new TLD from ICANN. These ITSPs will presumably want a private tree anyway so they don't disclose customer data or their network operations to competitors, avoid privacy & data protection complications, get round restrictions surrounding the use of the public tree, etc, etc. I simply cannot understand what advantages there are to having a private tree under some other to-be-agreed domain name that cannot be met by a private tree under e164.arpa. Remember that's the domain name IETF has decided gets used for ENUM. Could somebody *please* tell me what they can achieve under this mythical private tree that they could not achieve under a their own private e164.arpa tree? In fact, choosing another domain name is fraught with complications. Like choosing who will own and administer it. Or where that domain name would sit in the DNS. [Hey, let's put this private tree under JimsPrivateENUMTree.com and then watch the fun when I forget to renew the domain name registration with Verisign.] Or what controls the domain's owner would be able to apply and how they'd be policed. BTW, I think that choosing another domain name for a private tree will just add complexity and confusion, especially for applications. That will also hamper the update of ENUM and flatten the adoption curve. Somebody needs to state the glaringly obvious. Since nobody else has, here goes. No matter where an application lives -- inside a telco's net, on the public internet, in an intranet or extranet -- it must only make exactly 1 DNS lookup of exactly 1 domain name to figure out how a "call" gets routed. [That has to be the goal for ENUM, no matter whether it's User ENUM or Infrastructure ENUM or Operator ENUM, however these terms are understood.] After all, that's how the DNS works. Now when the application makes that lookup, it doesn't necessarily go to one set of name servers providing all three same name spaces. In a telco's net, the application queries the telco's DNS infrastructure which directs them to the telco's e164.arpa tree. On the internet, the application would see the public tree for e164.arpa. And on a corporate net, the application sees the company's private instance of e164.arpa because it queries the company's internal DNS infrastructure. It all just works. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Sun, 25 Jul 2004 14:47:22 -0400 From: Richard Shockey Date: Sun, 25 Jul 2004 14:47:22 -0400 To: enum at ietf.org Subject: [Enum] Agenda ENUM WG IETF 60 Message-ID: <6.1.0.6.2.20040723134502.0234aec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO WEDNESDAY, August 4, 2004 1130-1300 Break 1300-1500 Afternoon Sessions I IRTF asrg Anti Spam Working Group OPS capwap Control and Provisioning of Wireless Access Points WG OPS dnsop Domain Name System Operations WG * RTG rpsec Routing Protocol Security Requirements WG SEC krbwg Kerberos WG TSV enum Telephone and Number Mapping WG TSV mmusic Multiparty Multimedia Session Control WG * Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion:enum at ietf.org To Subscribe: enum-request at ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) ( appointment of scribe etc) Ok who wants to volunteer? # 1 Review of the ENUM Operations Document [ 10 Min] Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-00.txt Pages : 0 Date : 2004-7-12 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-00.txt # 2 Overview of the cost optimization of telecommunication connections based on ENUM as described in the ID "draft-bartosiewicz-enterprise-enum-00.txt".[ 10 Min] # 3 Disposition of [ 10 Min] Title : E.164 Number Mapping for the Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-04.txt Pages : 17 Date : 2004-6-8 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-04.txt I'd very much like to come to some conclusion on how this document should progress. IMHO it is an extremely valuable addition to the work effort but it has not had much discussion on the list. Perhaps Experimental. I dont know. As we see deployments progressing the entire issue of provisioning has not IMHO received sufficient attention. #4 ENUM VOID [ 10 Min] Title : IANA Registration for enumservice void Author(s) : R. Stastny, L. Conroy Filename : draft-stastny-enum-void-00.txt Pages : 7 Date : 2004-7-13 This document registers the 'ENUMservice' 'void' using the URI scheme 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761 [2]. This 'ENUMservice' SHALL be used to indicate that the E.164 number or E.164 number range connected to the domain used in DNS as described in [2] is not assigned to an end-user in case of an E.164 number or to a communication service provider in case of an E.164 number range. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stastny-enum-void-00.txt Carrier - Infrastructure ENUM Mini-BOF [ 1 hour ] R. Stastny J. Seng co-chairs A. Introduction to the problem statement ( R. Shockey) NOTE to participants. The chairs wish to remind the list that the discussion of this topic in San Diego should follow the following guidelines. 1 What is the Problem Statement here 2. What are the Requirements that address the Problem. 3. Discussion of specific approaches to a solution are out of scope. This is what IETF BOF's do : define problems, scope requirements decide on next steps if any. To that end in mind we would appreciate if Penn Pfauts & Steve Lind could discuss their draft for 10min or so in that specifically and narrowly defined context. Title : A Combined User/Carrier ENUM Author(s) : P. Pfautz, S. Lind Filename : draft-pfautz-lind-enum-carrier-00.txt Pages : 5 Date : 2004-7-8 This document considers how so-called "carrier" or "infrastructure" ENUM and "end user" or "public" ENUM can share a single Tier 1 registry yet have independent Tier 2 providers. This approach allows the common cooperative infrastructure required by ENUM to be shared by end users and carriers reducing costs and facilitating adoption of ENUM generally. The essence of the proposal is to populate the Tier 1 registry with non-terminal NAPTRs rather than NS records and use different ENUM service fields for carrier and end user records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-00.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Sun, 25 Jul 2004 14:47:22 -0400 From: Richard Shockey Date: Sun, 25 Jul 2004 14:47:22 -0400 To: enum at ietf.org Subject: [Enum] on the enumservice VOID document. Message-ID: <6.1.0.6.2.20040725142616.03b56cc0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO I think this is a excellent document that clearly defines a real problem and proposes IMHO the correct solution. And I'd like additionally to take it as a action item to work with the authors in the IPTEL WG to create the ENUM=YES dip indicator for tel URL's since that draft is inching closer to last call. Both of these will assist CUA's in making correct signalling & routing decisions and avoid useless and redundant queries. I have no problem with this document with the minor exception that I would change the example to something like mailto:num-info at carrier.org.foo or something that does not potentially refer to a real domain. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Sun, 25 Jul 2004 15:15:45 -0400 From: Richard Shockey Date: Sun, 25 Jul 2004 15:15:45 -0400 To: "Pfautz, Penn L, ALABS" Subject: RE: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" In-Reply-To: <34DA635B184A644DA4588E260EC0A25A07BA1530@ACCLUST02EVS1.ugd.att.com> Message-ID: <6.1.0.6.2.20040725144115.03bed448@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 04:57 PM 7/23/2004, Pfautz, Penn L, ALABS wrote: content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Richard: The basic problem I'm trying to address is how the use of ENUM for carrier interconnection can coexist with its use by end users, the latter of which I take as a given based on what has transpired in the IETF and ITU. Penn I know exactly what you are trying to address but I'm of the personal opinion that the two issues are orthogonal and that the use of the e164.arpa tree 1. creates an entirely new set of behaviors for CUA resolvers that were not originally anticipated 2. binding the two so closely to e164.arpa creates many of the same political problems we see in "public ENUM" re getting actual delegations from the NRA's and the rules NRA will bind to the use of those delegations. If end user choice is a possibility, then there are issues with what to do if the end user wishes to register something other than a the carrier info and vice versa. I don't believe this always requires two queries, and, in fact, that's what I'm trying to avoid. Avoidance of two queries would certainly be preferred but the practical problems An entity quering the proposed combined Tier 1 COULD get two NAPTRS back but might only get one. Even when two are returned, the calling party could choose to follow just one path, i.e. to prefer the end user or prefer the carrier path. Well if the query is done by an edge IP PBX the assumption is that it cannot read the carrier path and only can use the end user path. Presumably the carrier path eventually leads you to a terminal aka "u" NAPTR record for something like a LDAP that has AA associated with it? If carrier ENUM is in a separate tree then I have to do two queries to determine that there is a record in neither versus one under my proposal. Finally, I don't think my proposal in any way implies that carriers have a right to ENUM records absent a national opt-in decision. Oh .. I dont believe that at all. If, for instance, German regulators opt out of e164.arpa because they still have this "thing" about .apra there is no reason a group of them could not agree to privately aggregate their endpoints in either a public or private tree in .DE order optimize their internal routing or promote the notion of SIP end to end calling. People can and do anything they want to with the DNS and in fact that is what is happening now. In fact there are dozens of query response technologies that could work here 3761 only recommended one. In fact, by proposing a common Tier 1 rooted in cc.e164.arpa I pretty much make carrier ENUM depend on national opt-in to ENUM. Again ..why do you want that kind of dependency? Is is only because of the single query issue? his is why it is so important now that we all attempt to understand what is the real underlying problem statement and what are the functional requirements. Penn -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Stastny Richard Sent: Friday, July 23, 2004 2:06 PM To: Livingood, Jason; enum at ietf.org; Lind, Steven D, ALABS; Pfautz, Penn L, ALABS Subject: Re: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" I think before we get into technical discussions, e.g. how this fits with the DDDS algorithm and if it is wise to need always at least two ENUM queries to get an answer, we should try to find out if this solution really is what is required, if this solution in managable, etc. And last but not least, somebody needs to explain ITU-T and the national regulators (NRAs) that c.c.e164.arpa is not longer a national opt-in decision, because I as a carrier now have the RIGHT to have a delegation of my numbers in e164.arpa. nice try ;-) Richard -----Ursprüngliche Nachricht----- Von: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] Gesendet: Do 22.07.2004 17:28 An: enum at ietf.org; 'sdlind at att.com'; 'ppfautz at att.com' Cc: Betreff: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" Thanks to Penn and Steve for submitting this draft! It appears to present a workable technical solution to the discussions we've been having on infrastructure vs. end user ENUM (putting privacy concerns aside for a moment). I have minor comments / suggestions that may make this draft more usable in practice, and more acceptable to a wider audience. This involves a modification of the class of service acronyms. The draft proposes two class of service acronyms: 1. E2U - ENUM to URI, for End User records. 2. E2C - ENUM to Carrier, for Carrier or Service Provider records Which look like this, as cited in the draft: $Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa. IN NAPTR 100 50 "" "E2U" "" 9.0.3.5.7.6.8.7.9.4.1.joesenum.com IN NAPTR 100 50 "" "E2C" "" 9.0.3.5.7.6.8.7.9.4.1.telco.net I submit that in the practice of manually provisioning records in the DNS, in troubleshooting, or in general human use and reading of DNS records or query results, that "E2U" and "E2C" are simply to similar to one another visually. I think that in practice this could cause unnecessary difficulty and confusion. I would recommend that a different acronym be chosen for infrastructure uses that is unmistakably different from "E2U." This would pay heed to the human factors that will be present when dealing with a large number of these records day in and day out. The second concern is around the word "Carrier" and therefore the "C" portion of the class of service acronym. I believe that carrier is a rather limited description of the entities which may have networks and services associated with this class of service. I would suggest instead something focused on "service providers." For these two reasons, I think that the draft should modify the seconds acronym from "E2C" to something else, perhaps "SPR" (Service Provider Record) or "SPU" (Service Provider URI). Respectfully submitted, Jason Jason Livingood Director - Forward Looking Communication Services Communications Services Engineering Comcast Cable Communications 215-981-7813 jason_livingood at cable.comcast.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Sun, 25 Jul 2004 21:31:41 -0400 From: "Pfautz, Penn L, ALABS" Date: Sun, 25 Jul 2004 21:31:41 -0400 To: "Richard Shockey" Subject: RE: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" Message-ID: <34DA635B184A644DA4588E260EC0A25A07BA17AF@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Richard: I'd agree that if national regulators choose not authorize a delegation parties can and will look to private listing services, at least in principle. (Although some nations may take a heavier hand even about that). My hope is that it is not necessary to go down that path - and one of my arguments to those in the ITU concerned about control has been that if NRAs play dog in the manger they are likely to wind up having no say at all. In terms of whether non-carriers can read the carrier path, that remains to be seen. I still prefer a model in which, while carriers may keep internal routing data proprietary, they may make points-of-interconnection accessible to all. Penn -----Original Message----- From: Richard Shockey [mailto:richard at shockey.us] Sent: Sunday, July 25, 2004 2:57 PM To: Pfautz, Penn L, ALABS; Stastny Richard; Livingood, Jason; enum at ietf.org; Lind, Steven D, ALABS Subject: RE: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" At 04:57 PM 7/23/2004, Pfautz, Penn L, ALABS wrote: >content-class: urn:content-classes:message >Content-Type: text/plain; > charset="utf-8" > >Richard: > >The basic problem I'm trying to address is how the use of ENUM >for carrier interconnection can coexist with its use by end users, the >latter of which I take as a given based on what has transpired in the IETF >and ITU. Penn I know exactly what you are trying to address but I'm of the personal opinion that the two issues are orthogonal and that the use of the e164.arpa tree 1. creates an entirely new set of behaviors for CUA resolvers that were not originally anticipated 2. binding the two so closely to e164.arpa creates many of the same political problems we see in "public ENUM" re getting actual delegations from the NRA's and the rules NRA will bind to the use of those delegations. >If end user choice is a possibility, then there are issues with what to do >if the end user wishes to register something other than a the carrier info >and vice versa. >I don't believe this always requires two queries, and, in fact, that's >what I'm trying to avoid. Avoidance of two queries would certainly be preferred but the practical problems >An entity quering the proposed combined Tier 1 COULD get two NAPTRS back >but might only get one. Even when two are returned, the calling party >could choose to follow just one path, i.e. to prefer the end user or >prefer the carrier path. Well if the query is done by an edge IP PBX the assumption is that it cannot read the carrier path and only can use the end user path. Presumably the carrier path eventually leads you to a terminal aka "u" NAPTR record for something like a LDAP that has AA associated with it? >If carrier ENUM is in a separate tree then I have to do two queries to >determine that there is a record in neither versus one under my proposal. > >Finally, I don't think my proposal in any way implies that carriers have a >right to ENUM records absent a national opt-in decision. Oh .. I dont believe that at all. If, for instance, German regulators opt out of e164.arpa because they still have this "thing" about .apra there is no reason a group of them could not agree to privately aggregate their endpoints in either a public or private tree in .DE order optimize their internal routing or promote the notion of SIP end to end calling. People can and do anything they want to with the DNS and in fact that is what is happening now. In fact there are dozens of query response technologies that could work here 3761 only recommended one. > In fact, by proposing a common Tier 1 rooted in cc.e164.arpa I pretty > much make carrier ENUM depend on national opt-in to ENUM. Again ..why do you want that kind of dependency? Is is only because of the single query issue? his is why it is so important now that we all attempt to understand what is the real underlying problem statement and what are the functional requirements. >Penn > > >-----Original Message----- >From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of >Stastny Richard >Sent: Friday, July 23, 2004 2:06 PM >To: Livingood, Jason; enum at ietf.org; Lind, Steven D, ALABS; Pfautz, Penn >L, ALABS >Subject: Re: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" > > >I think before we get into technical discussions, e.g. how this fits with >the DDDS algorithm and >if it is wise to need always at least two ENUM queries to get an answer, >we should try to find >out if this solution really is what is required, if this solution in >managable, etc. > >And last but not least, somebody needs to explain ITU-T and the national >regulators (NRAs) >that c.c.e164.arpa is not longer a national opt-in decision, because I as >a carrier now have >the RIGHT to have a delegation of my numbers in e164.arpa. > > >nice try ;-) > >Richard > > -----Ursprüngliche Nachricht----- > Von: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] > Gesendet: Do 22.07.2004 17:28 > An: enum at ietf.org; 'sdlind at att.com'; 'ppfautz at att.com' > Cc: > Betreff: [Enum] Comments on "draft-pfautz-lind-enum-carrier-00.txt" > > > Thanks to Penn and Steve for submitting this draft! It appears > to present a workable technical solution to the discussions we've been > having on infrastructure vs. end user ENUM (putting privacy concerns > aside for a moment). > > I have minor comments / suggestions that may make this draft more > usable in practice, and more acceptable to a wider audience. This > involves a modification of the class of service acronyms. > > The draft proposes two class of service acronyms: > 1. E2U - ENUM to URI, for End User records. > 2. E2C - ENUM to Carrier, for Carrier or Service Provider records > > Which look like this, as cited in the draft: > $Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa. > IN NAPTR 100 50 "" "E2U" "" > 9.0.3.5.7.6.8.7.9.4.1.joesenum.com > IN NAPTR 100 50 "" "E2C" "" 9.0.3.5.7.6.8.7.9.4.1.telco.net > > I submit that in the practice of manually provisioning records in > the DNS, in troubleshooting, or in general human use and reading of DNS > records or query results, that "E2U" and "E2C" are simply to similar to > one another visually. I think that in practice this could cause > unnecessary difficulty and confusion. I would recommend that a different > acronym be chosen for infrastructure uses that is unmistakably different > from "E2U." This would pay heed to the human factors that will be > present when dealing with a large number of these records day in and day out. > > The second concern is around the word "Carrier" and therefore the > "C" portion of the class of service acronym. I believe that carrier is a > rather limited description of the entities which may have networks and > services associated with this class of service. I would suggest instead > something focused on "service providers." > > For these two reasons, I think that the draft should modify the > seconds acronym from "E2C" to something else, perhaps "SPR" (Service > Provider Record) or "SPU" (Service Provider URI). > > > Respectfully submitted, > > Jason > > > > Jason Livingood > Director - Forward Looking Communication Services > Communications Services Engineering > Comcast Cable Communications > 215-981-7813 > jason_livingood at cable.comcast.com > >_______________________________________________ >enum mailing list >enum at ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From fujiwara@jprs.co.jp Mon, 26 Jul 2004 12:30:03 -0400 From: fujiwara@jprs.co.jp Date: Mon, 26 Jul 2004 12:30:03 -0400 To: enum at ietf.org Subject: [Enum] ENUM+DNSSEC Trial in JAPAN Message-ID: <20040727.010522.116353904.fujiwara@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi, I'm Kazunori Fujiwara, JPRS and ETJP(ENUM Trial JAPAN). We developed ENUM+DNSSEC Registry system and added DNSSEC with our ETJP ENUM trial this March. I planed to report this DNSSEC+ENUM Trial if ENUM trial report session will be hold at the next IETF meeting. I want to discuss DNSSEC in ENUM in any places. Our system accepts NAPTR RRs and NS delegations at valiours delegation point (for both user ENUM trial and operator ENUM trial). and more, this system accepts DNSSEC DS RR with NS RR. and then, ENUM zone is signed after zone generation. we are using BIND-9.3.0rc. Sorry, there is no English documentation. Some infomation is in Yasuhiro Morishita's presentation at DNSSEC deployment workshop. http://www.sdl.sri.com/other/dnssec/DNSSEC04MayUS-Info.html Regards, -- Fujiwara, Kazunori JPRS _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Mon, 26 Jul 2004 13:45:41 -0400 From: "Peter Williams" Date: Mon, 26 Jul 2004 13:45:41 -0400 To: enum at ietf.org Subject: RE: [Enum] ENUM+DNSSEC Trial in JAPAN Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Can you state the main security objectives for the use of DNSSEC, please? For example: (1) enable users to validate "national authority" delegation of ENUM regions withing e164.arpa (2) enable users to establish a secure channel to a DNS server, when issuing queries (3) distribute public keys to VoIP users (4) use ENUM algorithm to locate public keys of DNS servers of private ENUM tress, and/or SIP proxies etc. From: fujiwara at jprs.co.jp To: enum at ietf.org Subject: [Enum] ENUM+DNSSEC Trial in JAPAN Date: Tue, 27 Jul 2004 01:05:22 +0900 (JST) Hi, I'm Kazunori Fujiwara, JPRS and ETJP(ENUM Trial JAPAN). We developed ENUM+DNSSEC Registry system and added DNSSEC with our ETJP ENUM trial this March. I planed to report this DNSSEC+ENUM Trial if ENUM trial report session will be hold at the next IETF meeting. I want to discuss DNSSEC in ENUM in any places. Our system accepts NAPTR RRs and NS delegations at valiours delegation point (for both user ENUM trial and operator ENUM trial). and more, this system accepts DNSSEC DS RR with NS RR. and then, ENUM zone is signed after zone generation. we are using BIND-9.3.0rc. Sorry, there is no English documentation. Some infomation is in Yasuhiro Morishita's presentation at DNSSEC deployment workshop. http://www.sdl.sri.com/other/dnssec/DNSSEC04MayUS-Info.html Regards, -- Fujiwara, Kazunori JPRS _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Mon, 26 Jul 2004 14:39:58 -0400 From: Jim Reid Date: Mon, 26 Jul 2004 14:39:58 -0400 To: "Peter Williams" Subject: Re: [Enum] ENUM+DNSSEC Trial in JAPAN In-Reply-To: Message-ID: <10536.1090866511@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO >>>>> "Peter" == Peter Williams writes: Peter> Can you state the main security objectives for the use of Peter> DNSSEC, please? The Security Considerations section of RFC3761 already makes this clear. Peter> (1) enable users to validate "national authority" Peter> delegation of ENUM regions withing e164.arpa Peter> (2) enable users to establish a secure channel to a DNS Peter> server, when issuing queries Peter> (3) distribute public keys to VoIP users Peter> (4) use ENUM algorithm to locate public keys of DNS servers Peter> of private ENUM tress, and/or SIP proxies DNSSEC provides for authenticity and non-repudiation of data in DNS responses using public key crypto and digital signatures. ie I can lookup your domain name in the DNS and prove that the answer I got back came from you and wasn't tampered with after it left your name server. The DNS as we know it today does not have these safeguards. In the context of ENUM the implication for that should be obvious: spoofed DNS responses could be used to hijack telephone service or worse. Likewise, retrieving keys from the DNS only makes sense if the responses from the DNS can be validated. FYI, DNSSEC does not provide a "secure channel" between client and server. It does not encrypt the data being sent in either direction. For more info, consult the latest internet drafts on DNSSEC. draft-ietf-dnsext-dnssec-intro-11.txt is an excellent primer on this important new protocol. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Mon, 26 Jul 2004 15:23:45 -0400 From: "Peter Williams" Date: Mon, 26 Jul 2004 15:23:45 -0400 To: jim at rfc1035.com Subject: Re: [Enum] ENUM+DNSSEC Trial in JAPAN Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Jim, Ive watched the DNSSEC since Jim Galvin et al. got frustrated with the infighting between DARPA/NSA over a particular (private) contract for PKI (and then a PKI-security management model for SNMPv3 [aborted by ISESG due to over politiking]), and went with the competive research area instead (with the relevant companies sulking in corner, basically, over money, prestige, etc). The camp played to the anti-PKI forces within IETF, who were foot stomping about the RSA patent at the time. This all got mixed up with the anti-ISO (X.500) camp within IETF, and the forces within NASA (my old haunt) and DARPA who were doing everything then could (including internal war) to dissuade NSA/DoD to adopt X.500 and GOSIP-based X.400 protocols for the DMS. We lost about 5-10 years progress applying intelligent lookup algorithms over this little affair. That the same folks are now running ICANN is worrying: the same issues are now facing the DNS itself, and more intelligent naming practices and usage models (see the VeriSign affair.) Whats never been clear in ENUM is how ENUM would *apply* DNS SEC. What the documents actually say is very little, and send some very poor signals to a reader about the relevance of DNS security to the processes of ENUM lookup, account provisioning, and protection of the DNS critical infrastructure itself (specific to ENUM management). That DNS SEC enables an RR to bear a signature is trivial part of the model: the architectural role of the secuity management system is what is important to understand: we cannot understand security infrastructure required for applying DNSSEC to ENUM without relating it to the ENUM's own distributed management infrastructure - a topic currently undergoing evolving design and discussion! Put it this way: it folks use XML to provision the records, and folks secure the XML transfer using SOAP, and secure the use of the XML records using SAML, then we know that DNSSEC did not address those critical needs. Some parallel infrastrucure did. In the IPSEC VPN world, we see a complete split between the security used for provisioning, and the security apparatus used for end-end internet protocols. The former are proprietary, and the standards are setup to continue the use of proprietary management protocols (e.g. with some system using the sidebands between the SONET repeaters in the backbones to faciliate realtime wiretapping and packet tracking at OC48 rates). The latter use internet standards of course, the former do not, and should not. The standard of course have some interplay, to ensure the providers can work both worlds together. I think there is a lot from the military X.500 security management architecture that we can reapply to the application of DNSSEC to the ENUM problem domain (assuming the chairs dont withold this area from IETF to maintain proprietary practices). Mitsuibishi in Japan have a lot of experience here from the JDF experience's of matching local lookup infrastructure to the US infrastructure for secure messaging and secure channel setup in tactical systems. Many of the issues found in tactical miltiary wireless systems will be applicable to VoiP to internet phones communicating setup using SIP sessions whose proxies are themselves provisioned via VPN management stations, using private DNS trees. From: Jim Reid To: "Peter Williams" CC: fujiwara at jprs.co.jp, enum at ietf.org Subject: Re: [Enum] ENUM+DNSSEC Trial in JAPAN Date: Mon, 26 Jul 2004 19:28:31 +0100 >>>>> "Peter" == Peter Williams writes: Peter> Can you state the main security objectives for the use of Peter> DNSSEC, please? The Security Considerations section of RFC3761 already makes this clear. Peter> (1) enable users to validate "national authority" Peter> delegation of ENUM regions withing e164.arpa Peter> (2) enable users to establish a secure channel to a DNS Peter> server, when issuing queries Peter> (3) distribute public keys to VoIP users Peter> (4) use ENUM algorithm to locate public keys of DNS servers Peter> of private ENUM tress, and/or SIP proxies DNSSEC provides for authenticity and non-repudiation of data in DNS responses using public key crypto and digital signatures. ie I can lookup your domain name in the DNS and prove that the answer I got back came from you and wasn't tampered with after it left your name server. The DNS as we know it today does not have these safeguards. In the context of ENUM the implication for that should be obvious: spoofed DNS responses could be used to hijack telephone service or worse. Likewise, retrieving keys from the DNS only makes sense if the responses from the DNS can be validated. FYI, DNSSEC does not provide a "secure channel" between client and server. It does not encrypt the data being sent in either direction. For more info, consult the latest internet drafts on DNSSEC. draft-ietf-dnsext-dnssec-intro-11.txt is an excellent primer on this important new protocol. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Mon, 26 Jul 2004 17:07:46 -0400 From: Jim Reid Date: Mon, 26 Jul 2004 17:07:46 -0400 To: "Peter Williams" Subject: Re: [Enum] ENUM+DNSSEC Trial in JAPAN In-Reply-To: Message-ID: <10815.1090875749@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO >>>>> "Peter" == Peter Williams writes: Peter> Whats never been clear in ENUM is how ENUM would *apply* Peter> DNS SEC. What the documents actually say is very little, Peter> and send some very poor signals to a reader about the Peter> relevance of DNS security to the processes of ENUM lookup, Peter> account provisioning, and protection of the DNS critical Peter> infrastructure itself (specific to ENUM management). That Peter> DNS SEC enables an RR to bear a signature is trivial part Peter> of the model: the architectural role of the secuity Peter> management system is what is important to understand: we Peter> cannot understand security infrastructure required for Peter> applying DNSSEC to ENUM without relating it to the ENUM's Peter> own distributed management infrastructure - a topic Peter> currently undergoing evolving design and discussion! If you think there's work to be done in this area, feel free to write up a draft or two. Or ask for some time in the WG agenda at IETF60. IMO, the security model here is a no-brainer. It just follows the general ENUM architecture and the hierarchical nature of DNSSEC. ie The key for e164.arpa signs the keys for "country code" delegations. What happens after that becomes a National Matter. The Tier-1 registry can then sign individual delegations or number blocks/ranges/area codes as it sees fit: whatever works best for the national numbering plan, telco regulatory considerations, DNS administration, competition, etc, etc. There may be trade-offs to be made here and these could be a good topic for the WG to consider. Another area the WG could look at is signing policies and key management: how often keys should be changed, signature durations and so on. That may be out of scope for the WG or require crypto expertise that isn't available here. What would be on-topic for this WG IMO could/should be a deployment & migration strategy for DNSSEC under e164.arpa. For example, how does a dumb device validate signed responses? What should/must a client do when validation fails? What are the trust relationships and how are these documented? To some extent, this work will get under way once the dnsext WG throws DNSSECbis over the wall. Which should be Real Soon Now. Hopefully. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum