From shollenbeck@verisign.com Mon, 01 Nov 2004 10:54:06 -0500 From: "Hollenbeck, Scott" Date: Mon, 01 Nov 2004 10:54:06 -0500 To: "'enum at ietf.org> Subject: [Enum] FW: objections: draft-ietf-enum-epp-e164-06.txt Message-ID: <7468147AEE316B41B3B55152959CE21825F10D@dul1wnexm05.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R The note below was held for moderator approval. I'm forwarding a copy at the request of the author. -Scott- -----Original Message----- From: Frank Thompson [mailto:fot at ca.afilias.info] Sent: Wednesday, October 27, 2004 4:25 PM To: Hollenbeck, Scott Cc: 'iesg at iesg.org'; 'ietf at ietf.org'; enum at ietf.org Subject: RE: objections: draft-ietf-enum-epp-e164-06.txt On Wed, 27 Oct 2004, Hollenbeck, Scott wrote: > Frank, > > I'm still trying to understand the points you are trying to make. I'm not > sure if I've been successful, so I'll try instead to respond to specific > points in the hope that it all makes sense when taken as a whole. > > Comments inline below. > > -Scott- Scott, I have read your comments and I can see now that the current draft will support both the NS delegation model and NAPTR delegation model with no changes needed. If one chooses to use NS delegation, they simply do not include the extension and likewise if they choose to use NAPTR delegation include the extension. The grounds for my argument were the result of the implementation I was asked to support which included at the time , , and . Since and have no clear direction in the context of this draft, the optional support I was looking for can easily be found in the base epp standard by default as 's are already optional. Thank you for making what should have been an obvious observation clear in your comment below, it became apparent as soon as I read your comment that the current EPP and the E164 draft could work without modification. Therefore, at this time I would like to formally withdraw the objection to the draft, sorry for the confusion this may have caused and thanks for taking the time to comment on my objection. frank > > > -----Original Message----- > > From: ietf-bounces at ietf.org [mailto:ietf-bounces at ietf.org] On > > Behalf Of Frank Thompson > > Sent: Monday, October 25, 2004 2:21 PM > > To: iesg at iesg.org > > Cc: ietf at ietf.org > > Subject: objections: draft-ietf-enum-epp-e164-06.txt > > > > > > Hi All, > > > > I would like to raise an issue with this draft which is > > currently in "Last > > Call" in regards to the storage of the extension element: > > [snip] > > > Objection: > > > > The mandatory inclusion of one or more elements is > > the major point of contension. By way of using the current > > epp schema for > > domain mapping, elements may be used to point to > > external DNS servers > > which will host the owning NAPTR records. Thus creating a > > "thin" enum > > registry while still accepting and generating "referral" e164 > > domains. > > This allows the registry to host the native NAPTR records and > > all the > > personal details that come along with that data or allow an > > external name > > service to host these dynamic NAPTR records. > > Mandatory inclusion of the elements is the whole point of the > extension. If you only want elements, you don't use the > extension. Please note, too that elements are OPTIONAL. It is > already a supported feature of the specifications to allow > elements without name server delegation information, and vice-versa. > > > As a further extension to the current support for > > is > > the ability to allow or support. > > These would > > work much like the above approach, in that the zone generated > > by the registry would point to an external DNS that would > > then resolve > > the actual NAPTR records for public use. While these are > > more experimental > > additions, they are a valuable addition to the draft, while > > enum trials > > are taking place to see how usability case studies perform in > > the real world. > > There is no mention of CNAME or DNAME provisioning requirements in RFCs 3403 > or 3761. That being the case, I don't agree that they should be included in > this extension. If someone is using them for some experimental purpose, > they should write their own extension describing their use. > > > To ensure the integrity of the e164 domain, only one of > > the four > > types may be associated with an e164 domain at a time. The > > four types are > > , , and . This way the zone > > generated for the e164 domain names will have a deterministic > > output each > > and every time. > > As I said above, I disagree with the and > assertion. I also disagree that elements and > elements are mutually exclusive. If a particular operational scenario > requires use of one while excluding the other, the current specs already > support that. > > -Scott- > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From harald@alvestrand.no Mon, 01 Nov 2004 17:32:21 -0500 From: Harald Tveit Alvestrand Date: Mon, 01 Nov 2004 17:32:21 -0500 To: Frank Thompson Subject: [Enum] RE: objections: draft-ietf-enum-epp-e164-06.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Frank, I saw your withdrawal on the IETF list, at least. The repeated posting seems to be someone messing things up in China; it contains the following interesting headers: Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNwBc-0004xd-Eu; Sat, 30 Oct 2004 12:34:56 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm441842ed3; Sun, 31 Oct 2004 00:21:11 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd417e841a; Wed, 27 Oct 2004 01:02:52 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1a417e85b4; Wed, 27 Oct 2004 01:02:51 +0800 I certainly hope the person involved will stop that! Harald --On mandag, november 01, 2004 08:46:49 -0500 Frank Thompson wrote: Hi Scott or Richard, I posted a withdraw of the objection last week, however I also received a message back saying that it was not accepted and that a moderator would have to approve it ? Its been more than 5 days now and it has not appeared in the archive nor have I been sent a confirmation, could one of you post it to the list so that it is not left as an open issue. thanks frank _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jaap@NLnetLabs.nl Tue, 02 Nov 2004 03:32:22 -0500 From: Jaap Akkerhuis Date: Tue, 02 Nov 2004 03:32:22 -0500 To: "Hollenbeck, Scott" Subject: Re: [Enum] FW: objections: draft-ietf-enum-epp-e164-06.txt In-Reply-To: <7468147AEE316B41B3B55152959CE21825F10D@dul1wnexm05.vcorp.ad.vrsn.com> Message-ID: <200411020826.iA28Qx9h043642@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain Status: R The note below was held for moderator approval. I'm forwarding a copy at the request of the author. It got probably lost in the tons of spam. Sorry about that. jaap _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Patrick.Guillemin@etsi.org Thu, 04 Nov 2004 12:30:44 -0500 From: =?iso-8859-1?Q?Patrick_Ren=E9_Guillemin?= Date: Thu, 04 Nov 2004 12:30:44 -0500 To: "Plugtests" Subject: [Enum] Invitation to register to the 2nd ENUM Workshop at ETSI on Tuesday 30 November 2004 Message-ID: <4091553999CBE4409CC2B562152B5A33049540CF@email10.etsihq.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Invitation to register to the 2nd ENUM Workshop at ETSI on Tuesday 30 November 2004 Dear All, 2nd ENUM Technical Workshop Event description & information www.etsi.org/plugtests/ENUM.htm Agenda www.etsi.org/plugtests/Upcoming/ENUM/ENUMAgenda.htm Registration webapp.etsi.org/meetingcalendar/MeetingDetails.asp?mid=24578 Please forward in your preferred lists. Best Regards Patrick GUILLEMIN ETSI - Plugtests Technical Coordinator www.etsi.org/plugtests _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bhoeneis@switch.ch Fri, 05 Nov 2004 05:16:04 -0500 From: Bernie Hoeneisen Date: Fri, 05 Nov 2004 05:16:04 -0500 To: enum at ietf.org Subject: [Enum] Authors of validation docs decide to collaborate Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Dear IETF ENUMers! Concerning the ENUM Validation, two Internet Drafts have been published; draft-hoeneisen-enum-validation-epp-00.txt (by B. Hoeneisen, switch.ch) draft-mayrhofer-enum-validation-00.txt (by A. Mayrhofer et al., enum.at) Both documents address the same problem area: the provisioning of validation information. But each chooses a different approach towards its solution: Whereas the former mainly addresses the integration of validation information into EPP, the latter looks at the validation from a more common view. The authors of these documents agreed to collaborate in the further standardisation, with the common goal to produce a complementary set of standards, which can be widely used. Any feedback on this work is welcome. A. Mayrhofer et al., enum.at B. Hoeneisen, switch.ch _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon, 08 Nov 2004 09:50:05 -0500 From: Richard Shockey Date: Mon, 08 Nov 2004 09:50:05 -0500 To: enum at ietf.org Subject: [Enum] Note on Agenda tonight...send me your slides if you can Message-ID: <6.1.2.0.2.20041108093105.056251f0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R so I can begin to collect them. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Wed, 17 Nov 2004 11:46:36 -0500 From: Richard Shockey Date: Wed, 17 Nov 2004 11:46:36 -0500 To: enum at ietf.org Subject: [Enum] Preliminary minutes ENUM WG IETF 61 Message-ID: <6.1.2.0.2.20041117113331.056d7ae0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Many thanks to Spencer Dawkins for his excellent notes. Telephone Number Mapping WG (enum) Monday, November 9 at 1930-2200 =============================== CHAIRS: Patrik Faltstrom Richard Shockey 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: AGENDA BASHING (5 min) Short Presentation on current status of ENUM in CC 1: Special Guest - Karen Mulberry MCI <>Karen is senior project manager for Numbering at MCI. She presented a Country Code 1 press release for a not-for-profit LLC (MCI, Sprint, Verizon are members now). $25K/year membership this year, all members equal, no limit on membership from interested parties, except cannot also be a vendor to the LLC. Most of the budget is liability insurance for the membership. 1. Problem is that 19 countries share "country code 1". This is the rat in the snake of ENUM deployment. All countries have to support delegation in order to make it happen. 2. Will write an RFC, will select one or more Tier One operators to operate a +1 ENUM registry. 3. Vision is that RFC goes to Tier Ones in June 2005, awarded/signed by October 2005, registry operational by January 2006. 4. http://www.enumllc.com is under construction now. 5. Are discussing a trial as soon as possible (before award, but after delegation). 6. Group is not chartered by anyone - US government has encouraged formation of this LLC, but can't be sure there are no alternatives in the woodpile. 7. IAB/ITU agreement is that ENUM delegation matches normal delegation perfectly. US and Canada can request the delegation, but no opposition is allowed (opposition will roadblock the delegation). 8. There is only one Tier One "A" vendors, but under that, there could be many Tier Two vendors. 1. [ 10 min] Shockey-Stastny The ENUM dip indicator. It is a draft that discusses the use of a ENUM dip indicator in the TEL URL that indicates that a ENUM query has been done. This is going to be discussed at IPTEL but we want to make everyone aware of it. New parameter for the "tel" URI to support ENUM, defined in http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt. * Support handling ENUM queries in SIP proxies, H.323 gatekeepers, other VoIP network elements. * Idea is that ENUM operations may result in repeated queries - want to give subsequent ENUM entities a list of queries that have already been performed, so they won't be repeated. This improves performance and reduces load on VoIP network elements. * Enumdi parameter isn't mandatory, so a VoIP network element that doesn't understand it will ignore it and still do the lookup. * Patrik - this needs to be a SHOULD NOT, not a MUST NOT. * Working group hum agrees... NEW ITEMS : We need to discuss whether the timing is correct to take on this as a WG item. 2. [20 M ] Title : An ENUM Registry Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-newton-iris-ereg-02.txt Pages : 45 Date : 2004-9-28 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt) registry schema for ENUM administrative information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-02.txt * IRIS uses multiple layers, XML, NAPTR records. * Want to provide ENUM Registry (EREG) . Similar to DREG registry, with its own identifier namespace. * Implementation available at irisverisignlabs.com. * Supports both UDP and TCP (using BEEP). * Does not require universal adoption Working group interest? Seems like enough interest to adopt, no opposition but a lot of "don't cares", too. Chairs Conclusion : Adopt as a WG item NEW ITEMS : These drafts relate to issues involving Validation of the Number Holder as part of the Provisioning process. 3. [20 M ] Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-hoeneisen-enum-validation-epp-00.txt Pages : 17 Date : 2004-9-30 This document describes an EPP extension for mapping information about the validation process the ENUM Registrar has applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-validation-epp-00.t xt * The goal here is to know a lot more about who registered an E.164 domain than we know about who registered a plain, vanilla DNS domain. * Austria, Switzerland, - who doesn't need something like this? We vote Country Code 1, of course, but no conclusions here (except that we know we have a problem). CC1 has external databases that you may not have in Europe, so not sure if CC1 would use the same approach or not. * This has a lot of interactions with number portability (which is done differently in CC1 and in Europe - they call-forward instead of doing a database lookup. * If your country code considers ENUM deployment, all these issues pop up instantly. 4. [ 20 M ] ENUM Validation Architecture and Token Format Definition - Alexander Mayrhofer A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-00.txt * What's the incentive for legacy carriers to contribute to validation for ENUM? We think it's close to zero. Most others (users, porting process/NPAC, etc.) are more likely to participate. * We need to accommodate consumer choice, not set up the next monopoly. * Centralized validation agents? Multiple validation agents? Number range holder = registrar? No single solution works best, so define Validation Entity as a role, not as an agency. * Question - where is the end user in all this? This validation flows one way (registrars validated registrants, not the other way around). What about the danger of slamming as we had in US long distance competition? * Question - we are getting from the problem statement to the solution - what are the requirements? Should a validation token be traceable to a verifier? * Question - are validation tokens signed, or encrypted and signed? Sweden has a distinction between validation entities and registration entities, and they don't share data, especially about customers. * Question - can the ENUM WG clear up the trust model here? * Question - what about cancelling tokens? New tokens override old ones, but there's an explicit cancel as well. What's still needed here? Definition of terms. Will this be one document or two (a framework and a specific implementation)? Will work on one document (framework, roles, requirements, definitions) during next IETF cycle (confirm this on the mailing list). ONGOING WORK: Title : IANA Registration for Enumservice VOID Author(s) : R. Stastny, L. Conroy Filename : draft-ietf-enum-void-00.txt Pages : 0 Date : 2004-10-12 This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt *** Older business: Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-01.txt Pages : 26 Date : 2004-10-25 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-01.txt * Want to get implementers' experience in next 30 days for WGLC by yearend. Title : IANA Registration for ENUMservices email, fax, mms, ems and sms Author(s) : R. Brandner, et al. Filename : draft-ietf-enum-msg-03.txt Pages : 20 Date : 2004-10-21 This document registers the 'ENUMservices' "email", "fax", "sms", "ems" and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-03.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 Wed, 24 Nov 2004 12:46:31 -0500 From: Richard Shockey Date: Wed, 24 Nov 2004 12:46:31 -0500 To: proceedings at ietf.org Subject: [Enum] Final meeting minutes ENUM WG IETF 61 Message-ID: <6.1.2.0.2.20041124123826.038ed5f0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Telephone Number Mapping WG (enum) Monday, November 9 at 1930-2200 =============================== CHAIRS: Patrik Faltstrom Richard Shockey 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/ Scribe: Spencer Dawkins - spencer at mcsr-labs.org AGENDA: AGENDA BASHING (5 min) Short Presentation on current status of ENUM in CC 1: Special Guest - Karen Mulberry MCI <>Karen is senior project manager for Numbering at MCI. She presented a Country Code 1 press release for a not-for-profit LLC (MCI, Sprint, Verizon are members now). $25K/year membership this year, all members equal, no limit on membership from interested parties, except cannot also be a vendor to the LLC. Most of the budget is liability insurance for the membership. 1. Problem is that 19 countries share "country code 1". This is the rat in the snake of ENUM deployment. All countries have to support delegation in order to make it happen. 2. Will write an RFC, will select one or more Tier One operators to operate a +1 ENUM registry. 3. Vision is that RFC goes to Tier Ones in June 2005, awarded/signed by October 2005, registry operational by January 2006. 4. http://www.enumllc.com is under construction now. 5. Are discussing a trial as soon as possible (before award, but after delegation). 6. Group is not chartered by anyone - US government has encouraged formation of this LLC, but can't be sure there are no alternatives in the woodpile. 7. IAB/ITU agreement is that ENUM delegation matches normal delegation perfectly. US and Canada can request the delegation, but no opposition is allowed (opposition will roadblock the delegation). 8. There is only one Tier One "A" vendors, but under that, there could be many Tier Two vendors. 1. [ 10 min] Shockey-Stastny The ENUM dip indicator. It is a draft that discusses the use of a ENUM dip indicator in the TEL URL that indicates that a ENUM query has been done. This is going to be discussed at IPTEL but we want to make everyone aware of it. New parameter for the "tel" URI to support ENUM, defined in http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt. * Support handling ENUM queries in SIP proxies, H.323 gatekeepers, other VoIP network elements. * Idea is that ENUM operations may result in repeated queries - want to give subsequent ENUM entities a list of queries that have already been performed, so they won't be repeated. This improves performance and reduces load on VoIP network elements. * Enumdi parameter isn't mandatory, so a VoIP network element that doesn't understand it will ignore it and still do the lookup. * Patrik - this needs to be a SHOULD NOT, not a MUST NOT. * Working group hum agrees... NEW ITEMS : We need to discuss whether the timing is correct to take on this as a WG item. 2. [20 M ] Title : An ENUM Registry Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-newton-iris-ereg-02.txt Pages : 45 Date : 2004-9-28 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt) registry schema for ENUM administrative information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-02.txt * IRIS uses multiple layers, XML, NAPTR records. * Want to provide ENUM Registry (EREG) . Similar to DREG registry, with its own identifier namespace. * Implementation available at irisverisignlabs.com. * Supports both UDP and TCP (using BEEP). * Does not require universal adoption Working group interest? Seems like enough interest to adopt, no opposition but a lot of "don't cares", too. Chairs Conclusion : Adopt as a WG item NEW ITEMS : These drafts relate to issues involving Validation of the Number Holder as part of the Provisioning process. 3. [20 M ] Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-hoeneisen-enum-validation-epp-00.txt Pages : 17 Date : 2004-9-30 This document describes an EPP extension for mapping information about the validation process the ENUM Registrar has applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-validation-epp-00.t xt * The goal here is to know a lot more about who registered an E.164 domain than we know about who registered a plain, vanilla DNS domain. * Austria, Switzerland, - who doesn't need something like this? We vote Country Code 1, of course, but no conclusions here (except that we know we have a problem). CC1 has external databases that you may not have in Europe, so not sure if CC1 would use the same approach or not. * This has a lot of interactions with number portability (which is done differently in CC1 and in Europe - they call-forward instead of doing a database lookup. * If your country code considers ENUM deployment, all these issues pop up instantly. 4. [ 20 M ] ENUM Validation Architecture and Token Format Definition - Alexander Mayrhofer A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-00.txt * What's the incentive for legacy carriers to contribute to validation for ENUM? We think it's close to zero. Most others (users, porting process/NPAC, etc.) are more likely to participate. * We need to accommodate consumer choice, not set up the next monopoly. * Centralized validation agents? Multiple validation agents? Number range holder = registrar? No single solution works best, so define Validation Entity as a role, not as an agency. * Question - where is the end user in all this? This validation flows one way (registrars validated registrants, not the other way around). What about the danger of slamming as we had in US long distance competition? * Question - we are getting from the problem statement to the solution - what are the requirements? Should a validation token be traceable to a verifier? * Question - are validation tokens signed, or encrypted and signed? Sweden has a distinction between validation entities and registration entities, and they don't share data, especially about customers. * Question - can the ENUM WG clear up the trust model here? * Question - what about cancelling tokens? New tokens override old ones, but there's an explicit cancel as well. What's still needed here? Definition of terms. Will this be one document or two (a framework and a specific implementation)? Will work on one document (framework, roles, requirements, definitions) during next IETF cycle (confirm this on the mailing list). ONGOING WORK: Title : IANA Registration for Enumservice VOID Author(s) : R. Stastny, L. Conroy Filename : draft-ietf-enum-void-00.txt Pages : 0 Date : 2004-10-12 This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt *** Older business: Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-01.txt Pages : 26 Date : 2004-10-25 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-01.txt * Want to get implementers' experience in next 30 days for WGLC by yearend. Title : IANA Registration for ENUMservices email, fax, mms, ems and sms Author(s) : R. Brandner, et al. Filename : draft-ietf-enum-msg-03.txt Pages : 20 Date : 2004-10-21 This document registers the 'ENUMservices' "email", "fax", "sms", "ems" and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-03.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