From enum-bounces@ietf.org Wed Apr 05 16:07:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREHO-0004Ow-VG; Wed, 05 Apr 2006 16:07:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRE41-0004Oc-Oj for enum@ietf.org; Wed, 05 Apr 2006 15:53:14 -0400 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRE3w-0008GY-JS for enum@ietf.org; Wed, 05 Apr 2006 15:53:09 -0400 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k35Jr6209641; Wed, 5 Apr 2006 15:53:06 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006040515530108493 ; Wed, 05 Apr 2006 15:53:01 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Apr 2006 15:53:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] IETF65 ENUM session minutes Date: Wed, 5 Apr 2006 15:53:00 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] IETF65 ENUM session minutes Thread-Index: AcZUloQQZCliTB1mSs2yjzxs0l+W+QEUjGfw From: "Mowafy, Hala" To: "Alexander Mayrhofer" , X-OriginalArrivalTime: 05 Apr 2006 19:53:01.0010 (UTC) FILETIME=[8B591320:01C658EA] X-Spam-Score: 0.5 (/) X-Scan-Signature: b94423d57458a72e07b422b40e685d94 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Thanks for the minutes. I see there was a request for a list of CNAM specs. The following should cover it: - Telcordia GR-1188-CORE: CLASS Feature: Calling Name Delivery Generic Requirements (December 2000) - ANSI T1.641-1995: Calling Name Identification Presentation - ANSI T1.639-1995: Calling Name Identification Restriction Hope this helps. Hala -----Original Message----- From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at]=20 Sent: Friday, March 31, 2006 2:31 AM To: 'enum@ietf.org' Subject: [Enum] IETF65 ENUM session minutes minutes are below - thanks to Spencer and Bernie for serving as scribes. ---- IETF65 (Dallas, TX) ENUM meeting minutes Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alex Mayrhofer Scribes: Spencer Dawkins Alex Mayrhofer Jabber Scribe: Bernie Hoeneisen Real Time Applications Infrastructure Area Director(s): Cullen Jennings Jon Peterson AGENDA BASHING (5 min) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Slight change to agenda - Patrik talks about 3761bis planned works first: RFC3761bis =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Patrik is not upping for IAB, so has time to update RFC3761 (3761bis), which is in line with WG milestone. A RT tracker system is set up for work on this document, issues should be opened as tickets in the system. One ticket per issue should be opened, there will be shared username/password for access to the system. Patrik will work on the individual issues, and resolve corresponding tickets once an issue is resolve. When all issues are resolved, the document should be ready. 3761bis does not exist as an draft yet - RT stuff will provide input for this. Patrik will do the editing. More info: http://www1.ietf.org/mail-archive/web/enum/current/msg04849.html Tickets could also affect other documents (conroy asks for DDDS issues). Shockey asks if guidance on non-terminals should go in there as well. Conroy suggests to put hints in 3761bis. patrik: operational experience stuff could go in seperate section or even document. ENUM Implementers Draft: (Final Version) 5 MIN =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-04.txt Pages : 37 Date : 2006-3-9 =09 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 advisory, 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-04.txt slides: http://www3.ietf.org/proceedings/06mar/slides/enum-8.ppt * Changes include section 6 (general DNS issues), request publication - Section 6 is biggest source of changes (others mostly editorial, seeking clarity, please give feedback for continued improvements). * Added size recommendations for EDNS0, intermediate system guidance, TTL and ANY (255) queries (this is a general DNS issue, but has been a problem in ENUM deployment - NAPTRs appear/disappear, etc.). * Please read and review - think we are finished, publish and update later if we need to. * Tim - "Non-terminal NAPTRs SHOULD NOT be used" - can't go quite this far - if you're gonna do this, it will take a long time - one third of the code on mobile clients deals with this. EDNS0 doesn't work with TCP, etc. - lots of things break. We'll talk offline, and this is a good WGLC comment. * EDNS0 is recommended here. May be spun off as separate document and just referenced here (if we can avoid dependencies). Still discussing MUST capitalization with DNSOPS reviewers. * Peter Koch: Implementation and OPS side is too much in one document - advocate separation. Having normative language for firewalls isn't appropriate in this standards track document. EDNS0 is a precondition for anything that uses DDDS - make a recommendation for minimum size in general, TCP, etc. * Conroy: Firewalls break DNS over TCP all by themselves, without any ENUM involved. Enumservices Guide =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Title : Guide and Template for IANA Registrations of Enumervices =09 [ 15 M ] Author(s) : J. Livingood, B. Hoeneisen Filename : draft-ietf-enum-enumservices-guide-00.txt Pages : 12 Date : 2006-2-27 =09 This document provides a guide to and template for the creation of new IANA registration of ENUM services. It is also to be used for updates of existing IANA registrations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-0 0.txt slides: http://www3.ietf.org/proceedings/06mar/slides/enum-4.ppt History: People filling out over and over again same sections with same content when doing Enumservice registrations. Standard template desired. request input for 3.2 ("Intended usage: COMMON") and 3.6 ("IANA Considerations"). Please post text or email privately. Section 3.2 - should a subtype always be given? should seperate subtypes have seperate registrations? for each URI scheme seperate? Statement on non-terminal NAPTRs? suggested answer: yes/yes/yes/no (with warning on non-terminals) Penn: didn't get a lot of guidance - would like template that includes cautions. cautions ok, but should actually tell you how to do this. Stastny: Usage of non-terminals need to be clarified before usage of them is advocated. shockey: should the behaviour regarding non terminals be in registration document itself? conroy: could imaging 2 ways to non-terminals. currently, missing flag indicates "non terminal", which is outside DDDS. If no flag is given, we can't do registrations, so seperate flag and seperate registration? no final conclusion about the four questions. CNAM =3D=3D=3D=3D Title : IANA Registration for an Enumservice and "tel" [ 15 Min ] Parameter for Calling Name Delivery(CNAM) Information Author(s) : R. Shockey, J. Livingood Filename : draft-shockey-enum-cnam-00.txt Pages : 10 Date : 2006-1-13 This document registers the Enumservice "cnam" and subtype "tel" using the URI scheme 'tel:', as per the IANA registration process defined in the ENUM specification, RFC 3761. In addition this document registers the parameter "cnam" in the IANA "tel" Parameter Registry defined in RFCXXX. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the PSTN that may be displayed on VoIP or other Real-time Client User Agents (CUA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shockey-enum-cnam-00.txt slides: http://www3.ietf.org/proceedings/06mar/slides/enum-6.ppt is about caller name display. info is requested in the US before callees phone rings. service assumes a private tree, with info not public. discussion about tel uri parameter vs. data uri. draft proposes tel parameter, but not sure about this (list discussions). What character set being used? No ultimate restriction, but PSTN limits to 15 characters in ASCII. How to interpret contents? DDDS says UTF-8, but there should be wording about this in there. Need to be aware what is about to being parsed (security considerations should point that out). List of CNAM specs to point people to is requested. Group agrees to adopt this as WG item - no "no" hums in room. tel or data URI? Paul primary objector, but not in the room. "tel" because this is a classic PSTN thing? Jon: don't compete with SIP caller name - what happens if both present? This needs to be interopable with normal SIP stuff. Jason: What if other providers don't have SIP URIs in their network, and are trying to limit the number of bits they are paying to store? Lawrence: Could have "network provided" and "user provided" numbers as well. this is for "network provided" - we use TXT in trials now. Jon: If network provided, don't we prefer to render that? Display name could be present in from tel or sip. data would never show up in SIP, but the servers or user agents would fetch it. depends all on call flows and use cases. don't couple with tel - would never appear in request. Jason/Richard: No preference, will dig deeper into data URI. IAX2 Enumservice: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Title : IANA Registration for IAX Enumservice [ 15 M ] Author(s) : E. Guy Filename : draft-ietf-enum-iax-00.txt Pages : 13 Date : 2006-2-22 =09 This document registers the IAX2 (Inter-Asterisk eXchange Version 2) Enumservice using the URI scheme 'iax2:' 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-iax-00.txt slides: http://www3.ietf.org/proceedings/06mar/slides/enum-7.pdf Need IAX2 URI registration, and a new template has shown up since last time. Some minor tech changes. Currently requested IESG review of protocol itself, will submit URI request using new template. Enumservice would need to go after URI registration (because RFC editors would need to perform edits otherwise). ENUM & Domainkeys =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Title : Telephone Number Mapping and Domain Keys as a Distributed Identity Infrastructure [ 15 M ] Author(s) : A. Mayrhofer Filename : draft-mayrhofer-enum-domainkeys-00.txt Pages : 10 Date : 2006-2-23 =09 This document creates a decentralized indentity infrastructure by combining technology from E.164 Number Mapping (ENUM) and DomainKeys Identified Mail (DKIM). This infrastructure uses E.164 numbers as identities, ENUM DNS for key distribution, and leverages the trust relations from ENUM validation to actual messages signed by the number holder. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-domainkeys-00.t xt slides: http://www3.ietf.org/proceedings/06mar/slides/enum-2.ppt # Not a full DDDS app, not a full Domain Keys app, so ... # Validation is most expensive part of ENUM provisioning - validation takes the identity to Internet domain - make use of this expense! # ENUM, not full DDDS # Domainkeys, but just key/storage # Validate that Sender has the same identiry as number holder # Available to any ENUM domain holder, no prior knowledge about sender required, any node on Internet can do this, domain internationally agreed, common validity. # Applications - signin to P2P networks, CLI signalling to PSTN, SPIT prevention. # Disconnected nodes could do authentication (with cached public keys) # Looking for opinions/feedback # Looking for crypto-PKI clue on co-authors # Steve Kent - you're going down to individual devices, right? form of identifier needs to be appropriate for applications. Going to this granularity needs to scale bigger than the DKIM application today, so think about scaling. (and why not DNSsec?) # Koch: How much do you want to trust DNS? You need DNSsec to trust this anyway, and if you do have DNSsec, maybe this would be enough. Cool ideas with deployment problems, probably premature, keep thinking. # David Schwartz - concerned about relying on PKI for individual certificates with no challenges, etc. E.164 numbers have geographic content, and this opens us up to some additional issues (beyond e-mail addresses). May need additional controls, may need to know who is verifying the numbers, etc. # SIP has made different tradeoffs, because of things like lack of huge installed base, etc. - have you looked at SIP Identity? There's a gap here that needs to be filled. # Penn Pfautz: Interesting idea, could be investigate further for usage even in carrier scenarios. Enumservice FOAF =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Title : IANA Registration for Enumservice foaf [ 15 Min ] Author(s) : K. Reichinger Filename : draft-reichinger-enum-foaf-00.txt Pages : 9 Date : 2006-2-15 This memo registers the Enumservice "foaf" using the URI schemes "http" and "https" according to the IANA Enumservice registration process defined in RFC3671. The Enumservice "foaf" is to be used to refer from an ENUM domain name to the location of a FOAF RDF file using the corresponding E.164 telephone number. Clients may use data retrieved from a FOAF RDF file to provide caller or callee with information available within the Friend-Of-A-Friend (FOAF) Semantic Web application. For example, the caller might be presented with personal information on the callee (e.g. name, gender and various online attributes) as well as information on the callee's social context (e.g. relations to friends or colleagues). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reichinger-enum-foaf-00.txt slides: http://www3.ietf.org/proceedings/06mar/slides/enum-3.ppt * FOAF is "Friend of a Friend" * Part of Semantic Web Project * Lots of terms defined already (in presentation) * Data is RDF-based and can be published anywhere on the web * Want to link FOAF data to phone number * Allows FOAF/ENUM spidering * Introduces ENUM to Semantic Web * Rohan - how do you find my FOAF data if I don't have a phone number today? Could be published on website, could appear as FOAF data under a related friend. * Richard Shockey - privacy issues seem astounding - how granular is privacy? File-by-file, so all-or-nothing. This is vCard-equivalent privacy - no, it's also other people's data in your profile, so it's more than vCard privacy issues. * Is this voluntary, like blogging? Yes. What applications read this information today? Don't think so, at the moment (but it's RDF-based). * Alex: Privacy question comes up for every service we talk about. Jason/Bernie - please point out that securing the underlying data isn't part of the ENUM service registration template, only the additional security issues of linking it to ENUM. * Rohan - there is a vCard security considerations list now - that's understood. What are we doing in ENUM if we make E.164 addresses more useful than other identifiers? Make a service discovery service, instead? * E.164 numbers are simply keys, period. * Patrik is concerned that the E.164 number becomes the FOAF identifier and should not be tied directly to the URI, which may move, etc. Lots of people are looking in this area (IRIS, Rohan, etc.). ENUM gives you URIs, not URNs. * What should we do with this document? The underlying protocols are experimental, so this should be, too. Need to publish something, so people know about the string - X-dash, for example? * Jon - don't actually know how to distinguish ENUM applications that use the same protocols (http) - need to figure out how to do this. * Rohan - if you have someone's web page and can't find their FOAF information, that's a Semantic Web issue that needs to be solved independently. (web page address could come from ENUM, FOAF to be discovered from there) * Rohan - need to come up with a generic way to do these registrations. Don't need to do much here except avoid conflicts. * Richard Shockey - would like to see one more spin of this document with updated registration template (draft previously discussed), but this is very interesting. IM Enumservice & Calendering Enumservice =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Title : A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services =09 [ 15 M ] Author(s) : R. Mahy Filename : draft-mahy-enum-im-service-00.txt Pages : 5 Date : 2006-2-22 =09 This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning im: URIs in ENUM. Title : A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services [ 15 M ] Author(s) : R. Mahy Filename : draft-mahy-enum-calendar-service-00.txt Pages : 5 Date : 2006-2-23 =09 This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning mailto: (iMIP) and http: (CalDAV) URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-enum-calendar-service-00. txt slides: http://www3.ietf.org/proceedings/06mar/slides/enum-5.ppt IM: --- * Was surprized that IM enumservice didn't exist, but it didn't exist. * Like pres URI, can only return IM URIs, and have a 3861 mechanism to discover correct/preferred protocol. * Comments? * Lawrence - this is fine. Not sure who will use this, because most IM users won't have SRV records. But no problem with the draft. * Room hummed to make thsi a WG draft Adopted as WG item. Calendar: --------- * Used to discover mailto and http(s) URIs for Internet calendaring services * Actually several subservices (manipulate calendar, check busy/free), including subservices that you can support in iCal, but not with IMAP. * Could this be merged with vCard transport? CALDEV doesn't really have a working group home (Calify has the right people) - but this isn't a generic vCard service. * Is this just traditional calendar events? There are a lot of possible calendars, which may be overlapping. Would this be better for the IETF Agenda? Rohan prefers to point to services with well-defined services. * Are we rolling too much stuff into ENUM? * Is this a WG item? Some number of hums in favor, fewer opposed. Adopted as WG item. Infrastructure Requirements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Title : Infrastrucure ENUM Requirements Author(s) : S. Lind, P. Pfautz [ 20 M ] Filename : draft-ietf-enum-infrastructure-enum-reqs-00.txt Pages : 7 Date : 2006-3-6 =09 This document provides requirements for "infrastructure" or "carrier" ENUM, defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum- reqs-00.txt slides: http://www3.ietf.org/proceedings/06mar/slides/enum-1.ppt * Lawrence - UK experience is that your "SHALL" should be "SHALL NOT" - anything that is public must not be able to identify the serving CSP... - this is the difference between "must have the capability" and "must turn the capability on". Have used cut-outs in the US for information like carrier-of-record. * If we're allowed to return anything, it would be carrier of record. * Richard Shockey - if you're going to do something like this, you have to have a WHOIS. * Next steps with this document? WGLC? Consensus to go for it. Combined User and Carrier ENUM =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D "Combined User and Carrier ENUM in the e164.arpa tree" - draft-haberler-carrier-enum-02.txt . [20 M] Abstract: ENUM as defined now in RFC3761 is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end-user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number. This document describes a minimally invasive scheme to provide both end-user and carrier data in ENUM. until it comes out of the queue, the I-D is available at: http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-02.txt slides: http://www3.ietf.org/proceedings/06mar/slides/enum-0.ppt # Consensus is to have one tree. In .arpa? IETF, IAB, RIPE, ITU-T involvement all needed, and existing policies/procedures can be reused. No time to come up with a new governing body and get agreement. # Above the country code, or below the country code? (or both places in parallel? - but would meet the requirements no matter where it is). # Above country code is most straight-forward solution (everything works), but has some constraints on timing for ITU-T concurrence. # Below country code is a national matter and can be implemented now. # Uses Branch Location Records (BLR). # Proposed to pursue both options in parallel, to allow trials using below country code. # Need RFC 3761bis to accomplish this. # Is BLR at the country level? No, location is a national matter ("below the zone cut"). # Lawrence - don't like TXT records. new RR is strongly recommended. Use TXT records for trials? # Richard Shockey - have never liked BLR (and never will). IAB isn't the decision-maker, it's IESG. # Patrik - ITU-T will be involved even if it's below the country code. # Lars - problem with TXT records. Can't stop you from using them for trials, but please make sure there are no collisions. # Richard Shockey - ITU-T will be involved, get used to it. # Patrik - in all the choices, so ITU-T involvement isn't a reason to pick one choice. # Richard Shockey - we need to expect 3GPP interest in carrier ENUM, too. # There are only about 300 records - why update millions of clients to recognize them? # May ITU-T meeting - need to do something about this very soon. # Patrik - do we disagree about above/below because we are missing requirements from the requirement documents? Should we have had more requirements? # Jon - remember that the IESG doesn't make decisions in a vacuum - IAB is part of the community that will be involved in any community decision. # Need to describe what's in DNS (label the boxes or your filing system will break down). Can't assume that all TXT records will "really" be BLRs. # There is a Draft Standard on handling unknown RR types (one of our few). # We all prefer option one, but what do we do in the interim? Alternative is that carriers will pick something, hopefully in the public parts of DNS, and then we'll TRY to tie things together. # Should this draft be a working group item? Richard Shockey doesn't think so - are we talking about having a separate domain for infrastructure ENUM? That's a separate document. Does not see BLR moving forward (unusual use of DNS). # Lawrence - don't like this, I'm worried about this, but the way ENUM is set up in the world, a global standard isn't going to happen quickly without something like this. # Richard Shockey - are BLRs a viable option? We took a hum, and lots of people said "yes". # Patrik - Some individuals violently disagree - can they go off to the bar and report back to the working group? On the Mailing list, this week. The outcome of bar discussions was later posted as the "Dallas Treaty": http://www1.ietf.org/mail-archive/web/enum/current/msg04848.html AOB =3D=3D=3D Koch: worried about potential size of DNS responses, number of ENUM services rising could lead to lots of TCP queries... meeting concluded. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 05 17:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFlD-0008FX-0H; Wed, 05 Apr 2006 17:41:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFlB-0008FS-Jp for enum@ietf.org; Wed, 05 Apr 2006 17:41:53 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFl9-0006td-EZ for enum@ietf.org; Wed, 05 Apr 2006 17:41:53 -0400 Received: from [10.31.13.237] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k35LgES8028115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2006 14:42:16 -0700 Message-ID: <4434398B.7040003@shockey.us> Date: Wed, 05 Apr 2006 17:41:31 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Mowafy, Hala" Subject: Re: [Enum] IETF65 ENUM session minutes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: c25c25eef92c03b403abac6c7c688517 Cc: enum@ietf.org, Alexander Mayrhofer X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Mowafy, Hala wrote: > Thanks for the minutes. I see there was a request for a list of CNAM > specs. > The following should cover it: > - Telcordia GR-1188-CORE: CLASS Feature: Calling Name Delivery Generic > Requirements (December 2000) > - ANSI T1.641-1995: Calling Name Identification Presentation > - ANSI T1.639-1995: Calling Name Identification Restriction yes it does .. thanks .. > > Hope this helps. > Hala > > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Sent: Friday, March 31, 2006 2:31 AM > To: 'enum@ietf.org' > Subject: [Enum] IETF65 ENUM session minutes > > > minutes are below - thanks to Spencer and Bernie for serving as scribes. > > ---- > IETF65 (Dallas, TX) ENUM meeting minutes > > Chair(s): > Patrik Faltstrom > Richard Shockey > > > WG Secretary: > Alex Mayrhofer > > Scribes: > Spencer Dawkins > Alex Mayrhofer > > Jabber Scribe: > Bernie Hoeneisen > > > Real Time Applications Infrastructure Area Director(s): > Cullen Jennings > Jon Peterson > > > AGENDA BASHING (5 min) > ====================== > > Slight change to agenda - Patrik talks about 3761bis planned works > first: > > RFC3761bis > ========== > > Patrik is not upping for IAB, so has time to update RFC3761 (3761bis), > which is in line with WG milestone. > > A RT tracker system is set up for work on this document, issues should > be opened as tickets in the system. One ticket per issue should be > opened, there will be shared username/password for access to the system. > > Patrik will work on the individual issues, and resolve corresponding > tickets once an issue is resolve. When all issues are resolved, the > document should be ready. 3761bis does not exist as an draft yet - RT > stuff will provide input for this. Patrik will do the editing. > > More info: > http://www1.ietf.org/mail-archive/web/enum/current/msg04849.html > > Tickets could also affect other documents (conroy asks for DDDS > issues). Shockey asks if guidance on non-terminals should go in there > as well. Conroy suggests to put hints in 3761bis. patrik: operational > experience stuff could go in seperate section or even document. > > ENUM Implementers Draft: (Final Version) 5 MIN > ============================================== > > Title : ENUM Implementation Issues and Experiences > Author(s) : L. Conroy, K. Fujiwara > Filename : draft-ietf-enum-experiences-04.txt > Pages : 37 > Date : 2006-3-9 > > 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 advisory, 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-04.txt > > slides: http://www3.ietf.org/proceedings/06mar/slides/enum-8.ppt > > * Changes include section 6 (general DNS issues), request publication - > Section 6 is biggest source of changes (others mostly editorial, seeking > clarity, please give feedback for continued improvements). > * Added size recommendations for EDNS0, intermediate system guidance, > TTL > and ANY (255) queries (this is a general DNS issue, but has been a > problem > in ENUM deployment - NAPTRs appear/disappear, etc.). > * Please read and review - think we are finished, publish and update > later > if we need to. > * Tim - "Non-terminal NAPTRs SHOULD NOT be used" - can't go quite this > far - > if you're gonna do this, it will take a long time - one third of the > code on > mobile clients deals with this. EDNS0 doesn't work with TCP, etc. - lots > of > things break. We'll talk offline, and this is a good WGLC comment. > * EDNS0 is recommended here. May be spun off as separate document and > just > referenced here (if we can avoid dependencies). Still discussing MUST > capitalization with DNSOPS reviewers. > * Peter Koch: Implementation and OPS side is too much in one document - > advocate separation. Having normative language for firewalls isn't > appropriate in this standards track document. EDNS0 is a precondition > for > anything that uses DDDS - make a recommendation for minimum size in > general, > TCP, etc. > * Conroy: Firewalls break DNS over TCP all by themselves, without any > ENUM > involved. > > Enumservices Guide > ================== > > Title : Guide and Template for IANA Registrations of > Enumervices > > [ 15 M ] > Author(s) : J. Livingood, B. Hoeneisen > Filename : draft-ietf-enum-enumservices-guide-00.txt > Pages : 12 > Date : 2006-2-27 > > This document provides a guide to and template for the creation of > new IANA registration of ENUM services. It is also to be used for > updates of existing IANA registrations. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-0 > 0.txt > > slides: http://www3.ietf.org/proceedings/06mar/slides/enum-4.ppt > > History: People filling out over and over again same sections with same > content when doing Enumservice registrations. Standard template desired. > > request input for 3.2 ("Intended usage: COMMON") and 3.6 ("IANA > Considerations"). Please post text or email privately. > > Section 3.2 - should a subtype always be given? should seperate subtypes > have seperate registrations? for each URI scheme seperate? > Statement on non-terminal NAPTRs? > > suggested answer: yes/yes/yes/no (with warning on non-terminals) > > Penn: didn't get a lot of guidance - would like template that includes > cautions. > cautions ok, but should actually tell you how to do this. > Stastny: Usage of non-terminals need to be clarified before usage of > them is advocated. > shockey: should the behaviour regarding non terminals be in registration > document itself? > conroy: could imaging 2 ways to non-terminals. currently, missing flag > indicates "non terminal", which is outside DDDS. If no flag is given, > we can't do registrations, so seperate flag and seperate registration? > > no final conclusion about the four questions. > > CNAM > ==== > > Title : IANA Registration for an Enumservice and "tel" [ 15 Min > ] > Parameter for Calling Name Delivery(CNAM) Information > Author(s) : R. Shockey, J. Livingood > Filename : draft-shockey-enum-cnam-00.txt > Pages : 10 > Date : 2006-1-13 > > This document registers the Enumservice "cnam" and subtype "tel" > using the URI scheme 'tel:', as per the IANA registration process > defined in the ENUM specification, RFC 3761. > > In addition this document registers the parameter "cnam" in the IANA > "tel" Parameter Registry defined in RFCXXX. This data is used to > facilitate the transfer of Calling Name Delivery (CNAM) data for > calls that originate on the PSTN that may be displayed on VoIP or > other Real-time Client User Agents (CUA). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shockey-enum-cnam-00.txt > > slides: http://www3.ietf.org/proceedings/06mar/slides/enum-6.ppt > > is about caller name display. info is requested in the US before > callees phone rings. service assumes a private tree, with info > not public. > > discussion about tel uri parameter vs. data uri. draft proposes tel > parameter, but not sure about this (list discussions). > > What character set being used? No ultimate restriction, but PSTN limits > to 15 characters in ASCII. How to interpret contents? DDDS says UTF-8, > but there should be wording about this in there. Need to be aware what > is about to being parsed (security considerations should point that > out). > List of CNAM specs to point people to is requested. > > Group agrees to adopt this as WG item - no "no" hums in room. > > tel or data URI? Paul primary objector, but not in the room. "tel" > because this is a classic PSTN thing? > Jon: don't compete with SIP caller name - what happens if both present? > This needs to be interopable with normal SIP stuff. > Jason: What if other providers don't have SIP URIs in their network, and > are trying to limit the number of bits they are paying to store? > Lawrence: Could have "network provided" and "user provided" numbers as > well. > this is for "network provided" - we use TXT in trials now. > Jon: If network provided, don't we prefer to render that? Display name > could be present in from tel or sip. data would never show up in SIP, > but the servers or user agents would fetch it. depends all on call flows > and use cases. don't couple with tel - would never appear in request. > Jason/Richard: No preference, will dig deeper into data URI. > > IAX2 Enumservice: > ================= > > Title : IANA Registration for IAX Enumservice [ 15 > M ] > Author(s) : E. Guy > Filename : draft-ietf-enum-iax-00.txt > Pages : 13 > Date : 2006-2-22 > > This document registers the IAX2 (Inter-Asterisk eXchange Version 2) > Enumservice using the URI scheme 'iax2:' 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-iax-00.txt > > slides: http://www3.ietf.org/proceedings/06mar/slides/enum-7.pdf > > Need IAX2 URI registration, and a new template has shown up since > last time. > Some minor tech changes. > Currently requested IESG review of protocol itself, will submit URI > request using new template. > Enumservice would need to go after URI registration (because RFC editors > would need to perform edits otherwise). > > ENUM & Domainkeys > ================= > > Title : Telephone Number Mapping and Domain Keys as a > Distributed > Identity Infrastructure [ 15 M ] > > Author(s) : A. Mayrhofer > Filename : draft-mayrhofer-enum-domainkeys-00.txt > Pages : 10 > Date : 2006-2-23 > > This document creates a decentralized indentity infrastructure by > combining technology from E.164 Number Mapping (ENUM) and DomainKeys > Identified Mail (DKIM). This infrastructure uses E.164 numbers as > identities, ENUM DNS for key distribution, and leverages the trust > relations from ENUM validation to actual messages signed by the > number holder. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-domainkeys-00.t > xt > > slides: http://www3.ietf.org/proceedings/06mar/slides/enum-2.ppt > > # Not a full DDDS app, not a full Domain Keys app, so ... > # Validation is most expensive part of ENUM provisioning - validation > takes > the identity to Internet domain - make use of this expense! > # ENUM, not full DDDS > # Domainkeys, but just key/storage > # Validate that Sender has the same identiry as number holder > # Available to any ENUM domain holder, no prior knowledge about sender > required, any node on Internet can do this, domain internationally > agreed, > common validity. > # Applications - signin to P2P networks, CLI signalling to PSTN, SPIT > prevention. > # Disconnected nodes could do authentication (with cached public keys) > # Looking for opinions/feedback > # Looking for crypto-PKI clue on co-authors > # Steve Kent - you're going down to individual devices, right? form of > identifier needs to be appropriate for applications. Going to this > granularity needs to scale bigger than the DKIM application today, so > think > about scaling. (and why not DNSsec?) > # Koch: How much do you want to trust DNS? You need DNSsec to trust this > anyway, and if you do have DNSsec, maybe this would be enough. Cool > ideas > with deployment problems, probably premature, keep thinking. > # David Schwartz - concerned about relying on PKI for individual > certificates with no challenges, etc. E.164 numbers have geographic > content, > and this opens us up to some additional issues (beyond e-mail > addresses). > May need additional controls, may need to know who is verifying the > numbers, > etc. > # SIP has made different tradeoffs, because of things like lack of huge > installed base, etc. - have you looked at SIP Identity? There's a gap > here > that needs to be filled. > # Penn Pfautz: Interesting idea, could be investigate further for usage > even in carrier scenarios. > > Enumservice FOAF > ================ > > Title : IANA Registration for Enumservice foaf [ 15 Min ] > > Author(s) : K. Reichinger > Filename : draft-reichinger-enum-foaf-00.txt > Pages : 9 > Date : 2006-2-15 > > This memo registers the Enumservice "foaf" using the URI schemes > "http" and "https" according to the IANA Enumservice registration > process defined in RFC3671. The Enumservice "foaf" is to be used to > refer from an ENUM domain name to the location of a FOAF RDF file > using the corresponding E.164 telephone number. > > Clients may use data retrieved from a FOAF RDF file to provide caller > or callee with information available within the Friend-Of-A-Friend > (FOAF) Semantic Web application. For example, the caller might be > presented with personal information on the callee (e.g. name, gender > and various online attributes) as well as information on the callee's > social context (e.g. relations to friends or colleagues). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-reichinger-enum-foaf-00.txt > > slides: http://www3.ietf.org/proceedings/06mar/slides/enum-3.ppt > > * FOAF is "Friend of a Friend" > * Part of Semantic Web Project > * Lots of terms defined already (in presentation) > * Data is RDF-based and can be published anywhere on the web > * Want to link FOAF data to phone number > * Allows FOAF/ENUM spidering > * Introduces ENUM to Semantic Web > * Rohan - how do you find my FOAF data if I don't have a phone > number > today? Could be published on website, could appear as FOAF data under a > related friend. > * Richard Shockey - privacy issues seem astounding - how granular is > privacy? File-by-file, so all-or-nothing. This is vCard-equivalent > privacy - > no, it's also other people's data in your profile, so it's more than > vCard > privacy issues. > * Is this voluntary, like blogging? Yes. What applications read this > information today? Don't think so, at the moment (but it's RDF-based). > * Alex: Privacy question comes up for every service we talk about. > Jason/Bernie - please point out that securing the underlying data isn't > part > of the ENUM service registration template, only the additional security > issues of linking it to ENUM. > * Rohan - there is a vCard security considerations list now - that's > understood. What are we doing in ENUM if we make E.164 addresses more > useful > than other identifiers? Make a service discovery service, instead? > * E.164 numbers are simply keys, period. > * Patrik is concerned that the E.164 number becomes the FOAF > identifier > and should not be tied directly to the URI, which may move, etc. Lots of > people are looking in this area (IRIS, Rohan, etc.). ENUM gives you > URIs, > not URNs. > * What should we do with this document? The underlying protocols are > experimental, so this should be, too. Need to publish something, so > people > know about the string - X-dash, for example? > * Jon - don't actually know how to distinguish ENUM applications > that > use the same protocols (http) - need to figure out how to do this. > * Rohan - if you have someone's web page and can't find their FOAF > information, that's a Semantic Web issue that needs to be solved > independently. (web page address could come from ENUM, FOAF to be > discovered from there) > * Rohan - need to come up with a generic way to do these > registrations. > Don't need to do much here except avoid conflicts. > * Richard Shockey - would like to see one more spin of this document > with updated registration template (draft previously discussed), but > this is > very interesting. > > IM Enumservice & Calendering Enumservice > ======================================== > > Title : A Telephone Number Mapping (ENUM) Service Registration > for Instant > Messaging (IM) Services > > [ 15 M ] > Author(s) : R. Mahy > Filename : draft-mahy-enum-im-service-00.txt > Pages : 5 > Date : 2006-2-22 > > This document registers a Telephone Number Mapping (ENUM) service for > Instant Messaging (IM). Specifically, this document focuses on > provisioning im: URIs in ENUM. > > > Title : A Telephone Number Mapping (ENUM) Service Registration > for Internet > Calendaring Services > [ 15 M ] > > Author(s) : R. Mahy > Filename : draft-mahy-enum-calendar-service-00.txt > Pages : 5 > Date : 2006-2-23 > > This document registers a Telephone Number Mapping (ENUM) service for > Internet Calendaring Services. Specifically, this document focuses > on provisioning mailto: (iMIP) and http: (CalDAV) URIs in ENUM. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mahy-enum-calendar-service-00. > txt > > slides: http://www3.ietf.org/proceedings/06mar/slides/enum-5.ppt > > IM: > --- > > * Was surprized that IM enumservice didn't exist, but it didn't > exist. > * Like pres URI, can only return IM URIs, and have a 3861 mechanism > to > discover correct/preferred protocol. > * Comments? > * Lawrence - this is fine. Not sure who will use this, because most > IM > users won't have SRV records. But no problem with the draft. > * Room hummed to make thsi a WG draft > > Adopted as WG item. > > Calendar: > --------- > > * Used to discover mailto and http(s) URIs for Internet calendaring > services > * Actually several subservices (manipulate calendar, check > busy/free), > including subservices that you can support in iCal, but not with IMAP. > * Could this be merged with vCard transport? CALDEV doesn't really > have > a working group home (Calify has the right people) - but this isn't a > generic vCard service. > * Is this just traditional calendar events? There are a lot of > possible > calendars, which may be overlapping. Would this be better for the IETF > Agenda? Rohan prefers to point to services with well-defined services. > * Are we rolling too much stuff into ENUM? > * Is this a WG item? Some number of hums in favor, fewer opposed. > > Adopted as WG item. > > Infrastructure Requirements > =========================== > > Title : Infrastrucure ENUM Requirements > Author(s) : S. Lind, P. Pfautz [ 20 > M ] > Filename : > draft-ietf-enum-infrastructure-enum-reqs-00.txt > Pages : 7 > Date : 2006-3-6 > > This document provides requirements for "infrastructure" or "carrier" > ENUM, defined as the use of RFC 3761 technology to facilitate > interconnection of networks for E.164 number addressed services, in > particular but not restricted to VoIP. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum- > reqs-00.txt > > slides: http://www3.ietf.org/proceedings/06mar/slides/enum-1.ppt > > * Lawrence - UK experience is that your "SHALL" should be "SHALL > NOT" - > anything that is public must not be able to identify the serving CSP... > - > this is the difference between "must have the capability" and "must turn > the > capability on". Have used cut-outs in the US for information like > carrier-of-record. > * If we're allowed to return anything, it would be carrier of > record. > * Richard Shockey - if you're going to do something like this, you > have > to have a WHOIS. > * Next steps with this document? WGLC? Consensus to go for it. > > Combined User and Carrier ENUM > ============================== > > "Combined User and Carrier ENUM in the e164.arpa tree" - > draft-haberler-carrier-enum-02.txt . > [20 M] > Abstract: > > ENUM as defined now in RFC3761 is not well suited for the purpose of > interconnection by carriers, as can be seen by the use of various > private tree arrangements based on ENUM mechanisms. A combined > end-user and carrier ENUM tree solution would leverage the ENUM > infrastructure in e164.arpa, increase resolution rates, and decrease > the cost per registered telephone number. This document describes a > minimally invasive scheme to provide both end-user and carrier data in > ENUM. > > until it comes out of the queue, the I-D is available at: > > http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-02.txt > > slides: http://www3.ietf.org/proceedings/06mar/slides/enum-0.ppt > > # Consensus is to have one tree. In .arpa? IETF, IAB, RIPE, ITU-T > involvement all needed, and existing policies/procedures can be reused. > No > time to come up with a new governing body and get agreement. > # Above the country code, or below the country code? (or both places in > parallel? - but would meet the requirements no matter where it is). > # Above country code is most straight-forward solution (everything > works), > but has some constraints on timing for ITU-T concurrence. > # Below country code is a national matter and can be implemented now. > # Uses Branch Location Records (BLR). > # Proposed to pursue both options in parallel, to allow trials using > below > country code. > # Need RFC 3761bis to accomplish this. > # Is BLR at the country level? No, location is a national matter ("below > the > zone cut"). > # Lawrence - don't like TXT records. new RR is strongly recommended. Use > TXT > records for trials? > # Richard Shockey - have never liked BLR (and never will). IAB isn't the > decision-maker, it's IESG. > # Patrik - ITU-T will be involved even if it's below the country code. > # Lars - problem with TXT records. Can't stop you from using them for > trials, but please make sure there are no collisions. > # Richard Shockey - ITU-T will be involved, get used to it. > # Patrik - in all the choices, so ITU-T involvement isn't a reason to > pick > one choice. > # Richard Shockey - we need to expect 3GPP interest in carrier ENUM, > too. > # There are only about 300 records - why update millions of clients to > recognize them? > # May ITU-T meeting - need to do something about this very soon. > # Patrik - do we disagree about above/below because we are missing > requirements from the requirement documents? Should we have had more > requirements? > # Jon - remember that the IESG doesn't make decisions in a vacuum - IAB > is > part of the community that will be involved in any community decision. > # Need to describe what's in DNS (label the boxes or your filing system > will > break down). Can't assume that all TXT records will "really" be BLRs. > # There is a Draft Standard on handling unknown RR types (one of our > few). > # We all prefer option one, but what do we do in the interim? > Alternative is > that carriers will pick something, hopefully in the public parts of DNS, > and > then we'll TRY to tie things together. > # Should this draft be a working group item? Richard Shockey doesn't > think > so - are we talking about having a separate domain for infrastructure > ENUM? > That's a separate document. Does not see BLR moving forward (unusual use > of > DNS). > # Lawrence - don't like this, I'm worried about this, but the way ENUM > is > set up in the world, a global standard isn't going to happen quickly > without > something like this. > # Richard Shockey - are BLRs a viable option? We took a hum, and lots of > people said "yes". > # Patrik - Some individuals violently disagree - can they go off to the > bar > and report back to the working group? On the Mailing list, this week. > > The outcome of bar discussions was later posted as the "Dallas Treaty": > http://www1.ietf.org/mail-archive/web/enum/current/msg04848.html > > > AOB > === > > Koch: worried about potential size of DNS responses, number of ENUM > services > rising could lead to lots of TCP queries... > > meeting concluded. > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 11 07:05:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTGgi-0005F4-JC; Tue, 11 Apr 2006 07:05:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTGgh-0005Ez-EQ for enum@ietf.org; Tue, 11 Apr 2006 07:05:35 -0400 Received: from mail.pts.se ([192.121.211.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTGgf-0004c6-Tw for enum@ietf.org; Tue, 11 Apr 2006 07:05:35 -0400 Received: from safir.pts.se (safir.pts.ad [192.121.215.23]) by mail.pts.se (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Tue, 11 Apr 2006 13:05:52 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: SV: [Enum] ENUM Working Group Last call on Infrastructure ENUMRequirements Date: Tue, 11 Apr 2006 13:05:30 +0200 Message-ID: <1050E7CDAF4ED042BA2096CC187A79A7027D11A9@safir.pts.ad> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] ENUM Working Group Last call on Infrastructure ENUMRequirements Thread-Index: AcZQcYY1Lqj+drJZRKWTY638iXz49wM4CrTg From: To: , X-Spam-Score: 0.8 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: fluffy@cisco.com, =?ISO-8859-1?Q?Patrik_F=E4ltstr?=, paf@cisco.com, jon.peterson@neustar.biz, tsg2q1@itu.int X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org HELLO We have some small comments on the I-D that now is on last call. Our comments follow the present structure of the ID. Clause 1.1 The second paragraph of 1.1 could be updated so E.164-number for mobile = service are included - see example below: The "carrier of record" will typically be a service provider authorized = to issue E.164 numbers for the provisioning of fixed (PSTN/ISDN) and = mobile (PLMN) communication services under the authority of a National = Regulatory Authority (NRA), but generally exhibits one or more of the = following properties: We are not so familiar with term "carrier of record" and the last = paragraph in 1.1 states that NRA shall ultimately determine this. We = think this I-D needs to define "carrier of records" and exactly explain = its meaning. The paragraph above gives the impression that the term is a = term of an SP (service provider). Clause 1.2 Is it correct understanding that the "infrastructure ENUM namespace" = could be in the .e164.apra used for User ENUM or in another public tree, = but should it only be in ONE or in many public trees? Later in this paragraph we think it is appropriate to delete the term = "closed" before NGN and also add mobile networks, i.e. PLMN. Clause 2 In 6) - we think "PLMN applications" could be added. In 7) the meaning of "discovery of unlisted numbers" is unclear and = might further description. In 8) B) only "open numbering plan" are mentioned but we hope the I-D = also cover "closed numbering plan". In 8 F) and G) the terms "end-user ENUM" and "private ENUM" are used - = this terms, together with User ENUM and infrastructure ENUM could be = defined in this I-D/RFC. Clause 3 The statements in the second paragraph about register all allocated = number to avoid identification of unlisted numbers is a little bit = unclear - please explain this better in the I-D/RFC Clause 5 The I-D author could correct the version number of [3] of ITU-T = Recommendation E.164 as he also is the editor of E.164. Sincerely Joakim Str=E5lmark Swedish Administration/NRA Tel. +46 70 811 40 64=20 -----Ursprungligt meddelande----- Fr=E5n: Richard Shockey [mailto:richard@shockey.us]=20 Skickat: den 25 mars 2006 21:52 Till: enum@ietf.org Kopia: Cullen Jennings; =3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr?=3D; =F6m; = Peterson,Jon =C4mne: [Enum] ENUM Working Group Last call on Infrastructure = ENUMRequirements Title : Infrastructure ENUM Requirements Author(s) : S. Lind, P. Pfautz Filename : draft-ietf-enum-infrastructure-enum-reqs-01.txt Pages : 8 Date : 2006-3-23 =09 This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-r= eqs-01.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. This document has been under extensive discussion since early 2005. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 3 weeks or so from Monday Mar 27 until at least April 17 though we can modify that if new issues come up. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 11 09:46:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJCL-0003nj-PS; Tue, 11 Apr 2006 09:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJCJ-0003mf-LH; Tue, 11 Apr 2006 09:46:23 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTJCI-0002O1-Uw; Tue, 11 Apr 2006 09:46:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Apr 2006 15:50:24 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4980@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URNs in ENUM (Laywer) Thread-Index: AcZcPUX3CXeUJsZrQvO368u8xXLwsAAjVDAQACjcZq0= From: "Stastny Richard" To: "Rosen, Brian" , "Henning Schulzrinne" , X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: ecrit@ietf.org Subject: [Enum] URNs in ENUM (Laywer) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 >telephone number. To make this work using service urns, you would have >to have the result of an enum dip for this number result in a urn that >is not currently a valid enum service. However, if you did make a new >service, it would work: Thank you for bringing this forward, I will crosspost this question to = the ENUM WG =20 I am not really sure if you need an new Enumservice at all =20 It depends if a service URN is a valid entry in a SIP URI If it is you do not even need a a new Enumservice to make this work, the "sip" Enumservice would be sufficient =20 The real problem here is again to locate the LoST service database =20 any comments here frem ENUM WG? =20 Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Mo 10.04.2006 20:24 An: Henning Schulzrinne Cc: ecrit@ietf.org Betreff: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02 Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 telephone number. To make this work using service urns, you would have to have the result of an enum dip for this number result in a urn that is not currently a valid enum service. However, if you did make a new service, it would work: e.164 is looked up in enum result is service urn urn is mapped with LoST call is sent where indicated, based on location of caller. Now, the caller would have to voluntarily put location on the call for this to work. I read: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. =20 quite literally. urn:service.sos is a validly-assigned URN because there is an RFC that says it is (which is the same as saying it's in the IANA registry of services). "Validly-assigned" does not mean "currently active in a domain" to me. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, April 09, 2006 9:23 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: Review of draft-ietf-ecrit-service-urn-02 More responses: On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > I have reviewed service-urn-02 and have the following comments: > > A little concerned about 1-800-LAWYER as an example. The problem here > is that there is no obvious mechanism to translate the e.164 > 1-800-LAWYER to the service urn. I suppose someone could propose an > enumservice for this purpose, but until they do, we might consider > removing this particular example Removing lawyers is always a good idea. (The similarity is that=20 dialing this number will get you a lawyer anywhere in the US, with=20 the law office depending on where you're calling from.) I don't quite=20 understand your concern about needing an enum service. > > You need a statement that points out the obvious: since the service=20 > urn > is a protocol labeling mechanism, it has no i18n implications. I'll add an I18N section. > > My biggest problem is the DDDS stuff (section 3). There is no > discussion of what domain you query the DNS for. This is an area well > worked over by other emergency stuff, and 'fragile' because what you > normally want is your "local" (as in access network) domain, and it's I don't think that's really true in general. Why should my access=20 network have better information about these services, particularly if=20 it has no interest in VoIP or emergency calls? I suspect that,=20 initially, the service lookup will be offered by the VSP. They have=20 an interest and obligation to provide the service and can't wait=20 until every last ISP has decided to provide a mapping service. > not all that easy to determine what that is. Read the HELD and LCP > documents, and the discussion about this point. I think this document > needs to handle this. I think whatever it says is likely to have=20 > to be > I didn't see any description of this in draft-winterbottom-geopriv- held-sighting-00. LCP seems to define, besides the usual suspects of=20 manual configuration and DHCP, a broadcast request, not specified=20 further. (This would be essentially a one-off version of SLP.) I think there are at least two plausible approaches to find an ISP- operated domain name, besides DHCP: (1) SLP or Bonjour; the practical problem is that SLP is seeing=20 limited new deployments and Bonjour seems to be under the cloud of=20 being non-IETF-developed (but comparatively widely deployed), with=20 the IETF competitor having been sent back to the WG for a do-over=20 (somebody might know more about this). (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain=20 name (via the usual reverse DNS lookup); use SRV or NAPTR record for=20 that domain. This relies on the user's public IP address having a DNS=20 entry. As far as I can tell, this seems to be almost universally true=20 for residential broadband. (For enterprise users, I suspect that the=20 DHCP solution is easiest.) I had suggested a version of (2). > the same as any other similar mechanism in the milieu (for example,=20 > how > you find your LoST server). We need to decide what this text is, and > copy it into all the relevant documents. Actually, you find your LoST server via this mechanism, since it=20 performs the translation. > > I am confused by the "Validation Mechanism" in Section 2. First of=20 > all > the word "resource" is used here for the first time. I am assuming it > has the meaning of 3406 resource. The real problem is that the=20 > section > in 3406 that talks about validity defines it as "is there a valid > service" rather than "is the service available". Using the DDDS > mechanism would only tell you if a service was available (in the sense > of configured, rather than in the sense of functioning) within a=20 > domain. > While I think you could keep most of this text if you qualify it, I > think the actual answer is that the validation mechanism is IANA > assignment. I agree that this doesn't quite fit; I reread 3406 and 3406 defines=20 validation thusly: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. =20 [...] This seems to imply that this mechanism would allow to determine=20 whether urn:service:timezone, say, exists or not. This would=20 presumably be done by the lookup mechanism. I'll reword the paragraph to hopefully make the distinction clearer. (more to follow) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 11 10:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJVt-0002uN-Dr; Tue, 11 Apr 2006 10:06:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJVr-0002uF-8C; Tue, 11 Apr 2006 10:06:35 -0400 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJVq-000311-2q; Tue, 11 Apr 2006 10:06:35 -0400 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id k3BE7rNd007820; Tue, 11 Apr 2006 10:07:54 -0400 Received: from trutkowski-desk.verisign.com ([10.169.64.230]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 10:06:25 -0400 Message-Id: <7.0.1.0.2.20060411095756.037293d0@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 11 Apr 2006 10:06:24 -0400 To: "Stastny Richard" , "Rosen, Brian" , "Henning Schulzrinne" , From: Tony Rutkowski Subject: Re: [Enum] URNs in ENUM (Laywer) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4980@oefeg-s04.oefeg.loc > References: <32755D354E6B65498C3BD9FD496C7D462C4980@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Apr 2006 14:06:25.0141 (UTC) FILETIME=[1E85CA50:01C65D71] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ecrit@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard et al., > >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 > >telephone number. To make this work using service urns, you would have > >to have the result of an enum dip for this number result in a urn that > >is not currently a valid enum service. However, if you did make a new > >service, it would work: Since this is an E.164 number and 800/freephone services/network elements are within the jurisdiction of the national telecom authority like the FCC, it would seem a NPRM would be necessary, followed by SDO action, e.g., INC. No? ==tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 11 10:10:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJZU-0004Zn-Ec; Tue, 11 Apr 2006 10:10:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJZS-0004Zf-LG; Tue, 11 Apr 2006 10:10:18 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTJZR-00035C-A7; Tue, 11 Apr 2006 10:10:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] URNs in ENUM (Laywer) Date: Tue, 11 Apr 2006 16:13:41 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4981@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] URNs in ENUM (Laywer) Thread-Index: AcZdcbZPVqVyYqDsTRK5ntV327FiUQAAGw9u From: "Stastny Richard" To: "Tony Rutkowski" , "Rosen, Brian" , "Henning Schulzrinne" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ecrit@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org NPRM, SDO, INC ? =20 Richard ________________________________ Von: Tony Rutkowski [mailto:trutkowski@verisign.com] Gesendet: Di 11.04.2006 16:06 An: Stastny Richard; Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Betreff: Re: [Enum] URNs in ENUM (Laywer) Richard et al., > >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 > >telephone number. To make this work using service urns, you would = have > >to have the result of an enum dip for this number result in a urn = that > >is not currently a valid enum service. However, if you did make a = new > >service, it would work: Since this is an E.164 number and 800/freephone services/network elements are within the jurisdiction of the national telecom authority like the FCC, it would seem a NPRM would be necessary, followed by SDO action, e.g., INC. No? =3D=3Dtony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 11 10:44:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTK6F-00014O-58; Tue, 11 Apr 2006 10:44:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTK6D-00013q-L7; Tue, 11 Apr 2006 10:44:09 -0400 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTK6B-0004FL-Ae; Tue, 11 Apr 2006 10:44:09 -0400 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id k3BEjhXP028762; Tue, 11 Apr 2006 10:45:43 -0400 Received: from trutkowski-desk.verisign.com ([10.169.64.230]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 10:43:57 -0400 Message-Id: <7.0.1.0.2.20060411102750.0371e470@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 11 Apr 2006 10:43:56 -0400 To: "Stastny Richard" , "Rosen, Brian" , "Henning Schulzrinne" , From: Tony Rutkowski Subject: Re: [Enum] URNs in ENUM (Laywer) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4981@oefeg-s04.oefeg.loc > References: <32755D354E6B65498C3BD9FD496C7D462C4981@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Apr 2006 14:43:57.0880 (UTC) FILETIME=[5D427B80:01C65D76] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ecrit@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, >NPRM Notice of Proposed Rulemaking. All changes to E.164 requirements and use in the U.S. is subject to the exclusive jurisdiction of the FCC pursuant to the Communications Act of 1996 and related judicial decisions. The FCC is obligated to proceed to make changes through a public consultative process consisting of a NPRM, followed by comments, reply comments, and implementing Orders. Some of this authority at the State level is shared with the Public Service Commissions through a separate consultative mechanism. The 800 number block and the associated services were the subject of extensive previous proceedings in conjunction with the rollout of the existing "ENUM" services based on the Intelligent Network. >SDO Standards Development Organization, e.g., ATIS, ETSI, etc. Some of these bodies have special regulatory related roles where E.164 number based resolvers/directories are concerned. >INC ? Industry Numbering Committee - an ATIS forum. See http://www.atis.org/inc/index.asp ATIS was created by the FCC at the time of the ATT breakup to serve as the industry wide forum for developing technical and administrative standards for the telecommunication infrastructure. Over the years - particularly in matters relating to signalling systems and practices, ATIS was regarded as the implementation mechanism for requirements established by the FCC. Its role is similar to both ETSI and and perhaps ERO/ENF. best, tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 11 12:27:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLiM-0005eq-Ta; Tue, 11 Apr 2006 12:27:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLEa-0008Sv-KY; Tue, 11 Apr 2006 11:56:52 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLEZ-0007Iu-9R; Tue, 11 Apr 2006 11:56:52 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3BFrKBW022711; Tue, 11 Apr 2006 15:53:20 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 11:53:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Apr 2006 11:53:18 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URNs in ENUM (Laywer) Thread-Index: AcZcPUX3CXeUJsZrQvO368u8xXLwsAAjVDAQACjcZq0ABFuGIA== From: "Rosen, Brian" To: "Stastny Richard" , "Henning Schulzrinne" , X-OriginalArrivalTime: 11 Apr 2006 15:53:20.0168 (UTC) FILETIME=[0E2D3A80:01C65D80] X-Spam-Score: 0.5 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 X-Mailman-Approved-At: Tue, 11 Apr 2006 12:27:38 -0400 Cc: ecrit@ietf.org Subject: [Enum] RE: URNs in ENUM (Laywer) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard Read what I wrote. The enum dip would return urn:service.lawyer You would use LoST (not SIP) to resolve it That would resolve to a sip uri I think that's a LoST enumservice, right? Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, April 11, 2006 9:50 AM To: Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Subject: URNs in ENUM (Laywer) >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 >telephone number. To make this work using service urns, you would have >to have the result of an enum dip for this number result in a urn that >is not currently a valid enum service. However, if you did make a new >service, it would work: Thank you for bringing this forward, I will crosspost this question to the ENUM WG =20 I am not really sure if you need an new Enumservice at all =20 It depends if a service URN is a valid entry in a SIP URI If it is you do not even need a a new Enumservice to make this work, the "sip" Enumservice would be sufficient =20 The real problem here is again to locate the LoST service database =20 any comments here frem ENUM WG? =20 Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Mo 10.04.2006 20:24 An: Henning Schulzrinne Cc: ecrit@ietf.org Betreff: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02 Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 telephone number. To make this work using service urns, you would have to have the result of an enum dip for this number result in a urn that is not currently a valid enum service. However, if you did make a new service, it would work: e.164 is looked up in enum result is service urn urn is mapped with LoST call is sent where indicated, based on location of caller. Now, the caller would have to voluntarily put location on the call for this to work. I read: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. =20 quite literally. urn:service.sos is a validly-assigned URN because there is an RFC that says it is (which is the same as saying it's in the IANA registry of services). "Validly-assigned" does not mean "currently active in a domain" to me. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, April 09, 2006 9:23 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: Review of draft-ietf-ecrit-service-urn-02 More responses: On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > I have reviewed service-urn-02 and have the following comments: > > A little concerned about 1-800-LAWYER as an example. The problem here > is that there is no obvious mechanism to translate the e.164 > 1-800-LAWYER to the service urn. I suppose someone could propose an > enumservice for this purpose, but until they do, we might consider > removing this particular example Removing lawyers is always a good idea. (The similarity is that=20 dialing this number will get you a lawyer anywhere in the US, with=20 the law office depending on where you're calling from.) I don't quite=20 understand your concern about needing an enum service. > > You need a statement that points out the obvious: since the service=20 > urn > is a protocol labeling mechanism, it has no i18n implications. I'll add an I18N section. > > My biggest problem is the DDDS stuff (section 3). There is no > discussion of what domain you query the DNS for. This is an area well > worked over by other emergency stuff, and 'fragile' because what you > normally want is your "local" (as in access network) domain, and it's I don't think that's really true in general. Why should my access=20 network have better information about these services, particularly if=20 it has no interest in VoIP or emergency calls? I suspect that,=20 initially, the service lookup will be offered by the VSP. They have=20 an interest and obligation to provide the service and can't wait=20 until every last ISP has decided to provide a mapping service. > not all that easy to determine what that is. Read the HELD and LCP > documents, and the discussion about this point. I think this document > needs to handle this. I think whatever it says is likely to have=20 > to be > I didn't see any description of this in draft-winterbottom-geopriv- held-sighting-00. LCP seems to define, besides the usual suspects of=20 manual configuration and DHCP, a broadcast request, not specified=20 further. (This would be essentially a one-off version of SLP.) I think there are at least two plausible approaches to find an ISP- operated domain name, besides DHCP: (1) SLP or Bonjour; the practical problem is that SLP is seeing=20 limited new deployments and Bonjour seems to be under the cloud of=20 being non-IETF-developed (but comparatively widely deployed), with=20 the IETF competitor having been sent back to the WG for a do-over=20 (somebody might know more about this). (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain=20 name (via the usual reverse DNS lookup); use SRV or NAPTR record for=20 that domain. This relies on the user's public IP address having a DNS=20 entry. As far as I can tell, this seems to be almost universally true=20 for residential broadband. (For enterprise users, I suspect that the=20 DHCP solution is easiest.) I had suggested a version of (2). > the same as any other similar mechanism in the milieu (for example,=20 > how > you find your LoST server). We need to decide what this text is, and > copy it into all the relevant documents. Actually, you find your LoST server via this mechanism, since it=20 performs the translation. > > I am confused by the "Validation Mechanism" in Section 2. First of=20 > all > the word "resource" is used here for the first time. I am assuming it > has the meaning of 3406 resource. The real problem is that the=20 > section > in 3406 that talks about validity defines it as "is there a valid > service" rather than "is the service available". Using the DDDS > mechanism would only tell you if a service was available (in the sense > of configured, rather than in the sense of functioning) within a=20 > domain. > While I think you could keep most of this text if you qualify it, I > think the actual answer is that the validation mechanism is IANA > assignment. I agree that this doesn't quite fit; I reread 3406 and 3406 defines=20 validation thusly: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. =20 [...] This seems to imply that this mechanism would allow to determine=20 whether urn:service:timezone, say, exists or not. This would=20 presumably be done by the lookup mechanism. I'll reword the paragraph to hopefully make the distinction clearer. (more to follow) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 11 14:20:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTNTf-00021B-Em; Tue, 11 Apr 2006 14:20:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTNTd-000211-LB for enum@ietf.org; Tue, 11 Apr 2006 14:20:33 -0400 Received: from fw-d-whp.denic.de ([81.91.160.27] helo=denic.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTNTc-0004CT-9x for enum@ietf.org; Tue, 11 Apr 2006 14:20:33 -0400 Received: by unknown.office.denic.de (Postfix, from userid 501) id 59CEB2A57ED; Tue, 11 Apr 2006 20:20:31 +0200 (CEST) Date: Tue, 11 Apr 2006 20:20:31 +0200 From: Peter Koch To: IETF ENUM WG Subject: Re: [Enum] ENUM Working Group Last call on ENUM Implementation Experiences Message-ID: <20060411182031.GD1162@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <442A9BC1.7090606@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <442A9BC1.7090606@shockey.us> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Wed, Mar 29, 2006 at 09:37:53AM -0500, Richard Shockey wrote: > http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-04.txt > > > The intent of the last call is to solicit comments before submitting the > ID to the IESG as a Proposed Standard. the document claims to be 'advisory', so I assume the intended status is "Informational". Still, I do not feel the draft is ready to go. It has a terminology issue, uses normative keywords without clear intention, and does not apply the robustness principle symmetrically. 1) Terminology The term 'zone' is used where 'domain', 'owner', or indeed 'zone' might be correct, depending on context. This occurs throughout the document, but it's not a simple search&replace exercise. 2) 'Normative' Keywords The abstract says the document is advisory and is reporting potential pitfalls. Section one again says the document is advisory and does not make the capitalized words 'normative', but gives little advice how to read them. In the security considerations section the observations and recommendations are named 'clarifications'. 3) Asymmetric application of the robustness principle Section 2 references the robustness principle; the 'recommendations' put most of the burden on the server side while at the same time allowing the client to 'bend' the rules, e.g.: 3.3: Servers "SHOULD" use '!' ... Clients "MAY" discard NAPTRs that do not use '!' The appropriate advice to the client would be to learn that there are other possible RegExp delimiters. There are also some nits (e.g. there's no truncated error response (6.2)) and some changes needed to the - mostly new - text in chapter 6. My personal feeling is that the EDNS0 discussion is too lengthy, as is that of inhomogeneous TTLs in an RRSet. More to the point, the 'recommendation' "All servers involved in ENUM resolution MUST support EDNS0" is not justified. While I'd agree that every name server should support EDNS0 plus a reasonable packet size, a MUST is appropriate only for those serving (XXL) NAPTR RRSets. The discussion of ANY queries in 6.5 should go into a separate section since it has little to do with TTLs. The motion is fine, though. Now if you've read this far you might think i dislike the draft. I do not. There are many valuable observations and food for future work (i.e. clarifications) in here that will help operators and implementors. I've left out some details here to meet the deadline. Those are still on my paper copy and i'll post or send them separately. And of course i'm happy to be pointed to earlier discussions i might have missed. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 11 15:32:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTObB-0005YE-SI; Tue, 11 Apr 2006 15:32:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTObA-0005XF-IH; Tue, 11 Apr 2006 15:32:24 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTObA-0006sA-9T; Tue, 11 Apr 2006 15:32:24 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FTOb1-0000Wd-3G; Tue, 11 Apr 2006 14:32:15 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Tony Rutkowski'" , "Rosen, Brian" , "'Henning Schulzrinne'" , Subject: RE: [Ecrit] Re: [Enum] URNs in ENUM (Laywer) Date: Tue, 11 Apr 2006 15:32:18 -0400 Message-ID: <015d01c65d9e$a7856130$4fe6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <32755D354E6B65498C3BD9FD496C7D462C4981@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZdcbZPVqVyYqDsTRK5ntV327FiUQAAGw9uAAsLPfA= X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ecrit@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org No, I don't think so. The number is in the NANP, and would be perfectly reasonable to exist in enum (any form of enum). The URI you get out could be a plain SIP URI, or it could be something else. One of the something else's could be a new enumservice (the LoST service) which could location-based-route the call to a SIP URI, which would then be routed as any other SIP URI would. But IANAL Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 11, 2006 10:14 AM To: Tony Rutkowski; Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] Re: [Enum] URNs in ENUM (Laywer) NPRM, SDO, INC ? Richard ________________________________ Von: Tony Rutkowski [mailto:trutkowski@verisign.com] Gesendet: Di 11.04.2006 16:06 An: Stastny Richard; Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Betreff: Re: [Enum] URNs in ENUM (Laywer) Richard et al., > >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 > >telephone number. To make this work using service urns, you would have > >to have the result of an enum dip for this number result in a urn that > >is not currently a valid enum service. However, if you did make a new > >service, it would work: Since this is an E.164 number and 800/freephone services/network elements are within the jurisdiction of the national telecom authority like the FCC, it would seem a NPRM would be necessary, followed by SDO action, e.g., INC. No? ==tony _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 11 15:41:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOjX-0000ne-6I; Tue, 11 Apr 2006 15:41:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOjW-0000lR-Bq for enum@ietf.org; Tue, 11 Apr 2006 15:41:02 -0400 Received: from wendolene.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTOjU-00075B-QE for enum@ietf.org; Tue, 11 Apr 2006 15:41:02 -0400 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by wendolene.rfc1035.com (8.13.6/8.12.10) with ESMTP id k3BJewjY011604; Tue, 11 Apr 2006 20:40:58 +0100 (BST) In-Reply-To: <20060411182031.GD1162@unknown.office.denic.de> References: <442A9BC1.7090606@shockey.us> <20060411182031.GD1162@unknown.office.denic.de> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <56EEA54D-0F24-40E4-9730-E6DABF914FA7@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] ENUM Working Group Last call on ENUM Implementation Experiences Date: Tue, 11 Apr 2006 20:40:52 +0100 To: Peter Koch X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: IETF ENUM WG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Apr 11, 2006, at 19:20, Peter Koch wrote: > More to the point, the 'recommendation' > "All servers involved in ENUM resolution MUST support EDNS0" is not > justified. While I'd agree that every name server should support > EDNS0 plus > a reasonable packet size, a MUST is appropriate only for those serving > (XXL) NAPTR RRSets. Peter, you're completely wrong about this. Sorry. A MUST for EDNS) is appropriate -- I'd say it's absolutely critical -- for anything involved in ENUM lookups. First off, even a modest NAPTR RRset will comfortably exceed a 512 byte payload. My ENUM zone (3.2.5.2.5.8.8.9.6.1.4.4.e164.arpa) contains 6 NAPTR RRs. Which is on the low side for reasonable usage. [Somehere around 10 NAPTRs seems likely to be the typical size of a real-world RRset.] My zone's RRset doesn't even include several mainstream URIs (like sms, mms, http or mailto) or funky ordering stuff for cute call routing: divert to voicemail, don't call my GSM, etc, etc. This lookup gets a 507 byte response. And that's with dropping potentially useful data from the Additional Section as well as optimal label compression. With EDNS0, the Additional Section isn't "truncated" and the full response is 602 bytes. Secondly, you have confused serving NAPTR RRsets with *resolving* them. Serving ENUM zones is just one part of the picture: and probably not the one that has the biggest operational impact. The draft says "All servers involved in ENUM resolution". The client doing the lookup or the server resolving that ENUM lookup does not have a priori knowledge of the size of the target zone's NAPTR RRset. It does not know if that zone has a small, "average" or XXL sized RRset. So the client and resolving server should plan for the worst. Or at least the typical ENUM response. Mandating EDNS0 with good buffer sizes is not only essential and prudent, it's just an application of the "be liberal in what you receive" principle. Even at 6 NAPTRs -- which is by no means XXL sized -- using EDNS0 is a Big Big Win. It saves truncation and TCP retries. Or more lookups to get the data that could/should have been in the Additional Section. That extra latency is bad news, especially on things like GPRS networks. We will have to sort this out over a few beers at RIPE52. :-) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 12 04:35:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTaob-0003bQ-KU; Wed, 12 Apr 2006 04:35:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTaoa-0003Rc-7Y; Wed, 12 Apr 2006 04:35:04 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTaoY-0004iT-Pm; Wed, 12 Apr 2006 04:35:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] URNs in ENUM (Laywer) Date: Wed, 12 Apr 2006 10:39:04 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4983@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] URNs in ENUM (Laywer) Thread-Index: AcZddvYA/eeTkTTQTAS7ZF+xcEy/3AAlOJP/ From: "Stastny Richard" To: "Tony Rutkowski" , "Rosen, Brian" , "Henning Schulzrinne" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ecrit@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Thanx Tony for this extensive explanations =20 So IMHO this is not so much an ENUM problem, but a problem of the definition of the service URNs =20 Before we define service URNs, we need to define what a service is ;-) =20 good luck =20 I see e.g. global services and local services all location based services are local services, as the name implies maybe we need a distinction in the service URN definition of a service is the same everywhere or if it is locally different. This also requires a definition of the related database e.g. LoST, etc. etc. =20 Richard ________________________________ Von: Tony Rutkowski [mailto:trutkowski@verisign.com] Gesendet: Di 11.04.2006 16:43 An: Stastny Richard; Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Betreff: Re: [Enum] URNs in ENUM (Laywer) Hi Richard, >NPRM Notice of Proposed Rulemaking. All changes to E.164 requirements and use in the U.S. is subject to the exclusive jurisdiction of the FCC pursuant to the Communications Act of 1996 and related judicial decisions. The FCC is obligated to proceed to make changes through a public consultative process consisting of a NPRM, followed by comments, reply comments, and implementing Orders. Some of this authority at the State level is shared with the Public Service Commissions through a separate consultative mechanism. The 800 number block and the associated services were the subject of extensive previous proceedings in conjunction with the rollout of the existing "ENUM" services based on the Intelligent Network. >SDO Standards Development Organization, e.g., ATIS, ETSI, etc. Some of these bodies have special regulatory related roles where E.164 number based resolvers/directories are concerned. >INC ? Industry Numbering Committee - an ATIS forum. See http://www.atis.org/inc/index.asp ATIS was created by the FCC at the time of the ATT breakup to serve as the industry wide forum for developing technical and administrative standards for the telecommunication infrastructure. Over the years - particularly in matters relating to signalling systems and practices, ATIS was regarded as the implementation mechanism for requirements established by the FCC. Its role is similar to both ETSI and and perhaps ERO/ENF. best, tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 12 04:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTayS-0000Pm-QX; Wed, 12 Apr 2006 04:45:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTayS-0000Pe-1U; Wed, 12 Apr 2006 04:45:16 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTayQ-0004sV-3k; Wed, 12 Apr 2006 04:45:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Apr 2006 10:49:15 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4984@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URNs in ENUM (Laywer) Thread-Index: AcZcPUX3CXeUJsZrQvO368u8xXLwsAAjVDAQACjcZq0ABFuGIAAjcBs9 From: "Stastny Richard" To: "Rosen, Brian" , "Henning Schulzrinne" , X-Spam-Score: 0.5 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: ecrit@ietf.org Subject: [Enum] Re: URNs in ENUM (Laywer) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hmm, =20 This could be done. OTOH, do all URN:service resolve with LoST =20 This seems a bit a chicken-and-egg problem if a user enters a service URN direct, there must be a way to resolve it within e.g. SIP anyway, so why burden ENUM resolvers with service resolving do it one after the other ENUM - SIP - LoST-SIP =20 especially if the UA is not capable of doing LoST so the service URN has to be forwarded to the proxy anyway via SIP =20 Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Di 11.04.2006 17:53 An: Stastny Richard; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Betreff: RE: URNs in ENUM (Laywer) Richard Read what I wrote. The enum dip would return urn:service.lawyer You would use LoST (not SIP) to resolve it That would resolve to a sip uri I think that's a LoST enumservice, right? Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 11, 2006 9:50 AM To: Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Subject: URNs in ENUM (Laywer) >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 >telephone number. To make this work using service urns, you would have >to have the result of an enum dip for this number result in a urn that >is not currently a valid enum service. However, if you did make a new >service, it would work: Thank you for bringing this forward, I will crosspost this question to the ENUM WG I am not really sure if you need an new Enumservice at all It depends if a service URN is a valid entry in a SIP URI If it is you do not even need a a new Enumservice to make this work, the "sip" Enumservice would be sufficient The real problem here is again to locate the LoST service database any comments here frem ENUM WG? Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Mo 10.04.2006 20:24 An: Henning Schulzrinne Cc: ecrit@ietf.org Betreff: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02 Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 telephone number. To make this work using service urns, you would have to have the result of an enum dip for this number result in a urn that is not currently a valid enum service. However, if you did make a new service, it would work: e.164 is looked up in enum result is service urn urn is mapped with LoST call is sent where indicated, based on location of caller. Now, the caller would have to voluntarily put location on the call for this to work. I read: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN.=20 quite literally. urn:service.sos is a validly-assigned URN because there is an RFC that says it is (which is the same as saying it's in the IANA registry of services). "Validly-assigned" does not mean "currently active in a domain" to me. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, April 09, 2006 9:23 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: Review of draft-ietf-ecrit-service-urn-02 More responses: On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > I have reviewed service-urn-02 and have the following comments: > > A little concerned about 1-800-LAWYER as an example. The problem here > is that there is no obvious mechanism to translate the e.164 > 1-800-LAWYER to the service urn. I suppose someone could propose an > enumservice for this purpose, but until they do, we might consider > removing this particular example Removing lawyers is always a good idea. (The similarity is that dialing this number will get you a lawyer anywhere in the US, with the law office depending on where you're calling from.) I don't quite understand your concern about needing an enum service. > > You need a statement that points out the obvious: since the service > urn > is a protocol labeling mechanism, it has no i18n implications. I'll add an I18N section. > > My biggest problem is the DDDS stuff (section 3). There is no > discussion of what domain you query the DNS for. This is an area well > worked over by other emergency stuff, and 'fragile' because what you > normally want is your "local" (as in access network) domain, and it's I don't think that's really true in general. Why should my access network have better information about these services, particularly if it has no interest in VoIP or emergency calls? I suspect that, initially, the service lookup will be offered by the VSP. They have an interest and obligation to provide the service and can't wait until every last ISP has decided to provide a mapping service. > not all that easy to determine what that is. Read the HELD and LCP > documents, and the discussion about this point. I think this document > needs to handle this. I think whatever it says is likely to have > to be > I didn't see any description of this in draft-winterbottom-geopriv- held-sighting-00. LCP seems to define, besides the usual suspects of manual configuration and DHCP, a broadcast request, not specified further. (This would be essentially a one-off version of SLP.) I think there are at least two plausible approaches to find an ISP- operated domain name, besides DHCP: (1) SLP or Bonjour; the practical problem is that SLP is seeing limited new deployments and Bonjour seems to be under the cloud of being non-IETF-developed (but comparatively widely deployed), with the IETF competitor having been sent back to the WG for a do-over (somebody might know more about this). (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain name (via the usual reverse DNS lookup); use SRV or NAPTR record for that domain. This relies on the user's public IP address having a DNS entry. As far as I can tell, this seems to be almost universally true for residential broadband. (For enterprise users, I suspect that the DHCP solution is easiest.) I had suggested a version of (2). > the same as any other similar mechanism in the milieu (for example, > how > you find your LoST server). We need to decide what this text is, and > copy it into all the relevant documents. Actually, you find your LoST server via this mechanism, since it performs the translation. > > I am confused by the "Validation Mechanism" in Section 2. First of > all > the word "resource" is used here for the first time. I am assuming it > has the meaning of 3406 resource. The real problem is that the > section > in 3406 that talks about validity defines it as "is there a valid > service" rather than "is the service available". Using the DDDS > mechanism would only tell you if a service was available (in the sense > of configured, rather than in the sense of functioning) within a > domain. > While I think you could keep most of this text if you qualify it, I > think the actual answer is that the validation mechanism is IANA > assignment. I agree that this doesn't quite fit; I reread 3406 and 3406 defines validation thusly: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN.=20 [...] This seems to imply that this mechanism would allow to determine whether urn:service:timezone, say, exists or not. This would presumably be done by the lookup mechanism. I'll reword the paragraph to hopefully make the distinction clearer. (more to follow) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 12 08:16:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeGO-0005Pk-VS; Wed, 12 Apr 2006 08:16:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeGN-0005Oi-Jc; Wed, 12 Apr 2006 08:15:59 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTeGN-0003bQ-7b; Wed, 12 Apr 2006 08:15:59 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3CCFRBW027580; Wed, 12 Apr 2006 12:15:27 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 08:15:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Apr 2006 08:15:24 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URNs in ENUM (Laywer) Thread-Index: AcZcPUX3CXeUJsZrQvO368u8xXLwsAAjVDAQACjcZq0ABFuGIAAjcBs9AAdPaCA= From: "Rosen, Brian" To: "Stastny Richard" , "Henning Schulzrinne" , X-OriginalArrivalTime: 12 Apr 2006 12:15:26.0973 (UTC) FILETIME=[C85BBAD0:01C65E2A] X-Spam-Score: 0.5 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: ecrit@ietf.org Subject: [Enum] RE: URNs in ENUM (Laywer) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org No, not all service urns resolve with LoST; only those which are location based. There is a defined procedure to resolve a service URN. I expect the enumservice is not really a LoST service, it's a service URN service, for which there is a defined resolution process. =20 Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Wednesday, April 12, 2006 4:49 AM To: Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Subject: Re: URNs in ENUM (Laywer) Hmm, =20 This could be done. OTOH, do all URN:service resolve with LoST =20 This seems a bit a chicken-and-egg problem if a user enters a service URN direct, there must be a way to resolve it within e.g. SIP anyway, so why burden ENUM resolvers with service resolving do it one after the other ENUM - SIP - LoST-SIP =20 especially if the UA is not capable of doing LoST so the service URN has to be forwarded to the proxy anyway via SIP =20 Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Di 11.04.2006 17:53 An: Stastny Richard; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Betreff: RE: URNs in ENUM (Laywer) Richard Read what I wrote. The enum dip would return urn:service.lawyer You would use LoST (not SIP) to resolve it That would resolve to a sip uri I think that's a LoST enumservice, right? Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 11, 2006 9:50 AM To: Rosen, Brian; Henning Schulzrinne; enum@ietf.org Cc: ecrit@ietf.org Subject: URNs in ENUM (Laywer) >Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 >telephone number. To make this work using service urns, you would have >to have the result of an enum dip for this number result in a urn that >is not currently a valid enum service. However, if you did make a new >service, it would work: Thank you for bringing this forward, I will crosspost this question to the ENUM WG I am not really sure if you need an new Enumservice at all It depends if a service URN is a valid entry in a SIP URI If it is you do not even need a a new Enumservice to make this work, the "sip" Enumservice would be sufficient The real problem here is again to locate the LoST service database any comments here frem ENUM WG? Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Mo 10.04.2006 20:24 An: Henning Schulzrinne Cc: ecrit@ietf.org Betreff: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02 Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 telephone number. To make this work using service urns, you would have to have the result of an enum dip for this number result in a urn that is not currently a valid enum service. However, if you did make a new service, it would work: e.164 is looked up in enum result is service urn urn is mapped with LoST call is sent where indicated, based on location of caller. Now, the caller would have to voluntarily put location on the call for this to work. I read: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN.=20 quite literally. urn:service.sos is a validly-assigned URN because there is an RFC that says it is (which is the same as saying it's in the IANA registry of services). "Validly-assigned" does not mean "currently active in a domain" to me. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, April 09, 2006 9:23 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: Review of draft-ietf-ecrit-service-urn-02 More responses: On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > I have reviewed service-urn-02 and have the following comments: > > A little concerned about 1-800-LAWYER as an example. The problem here > is that there is no obvious mechanism to translate the e.164 > 1-800-LAWYER to the service urn. I suppose someone could propose an > enumservice for this purpose, but until they do, we might consider > removing this particular example Removing lawyers is always a good idea. (The similarity is that dialing this number will get you a lawyer anywhere in the US, with the law office depending on where you're calling from.) I don't quite understand your concern about needing an enum service. > > You need a statement that points out the obvious: since the service > urn > is a protocol labeling mechanism, it has no i18n implications. I'll add an I18N section. > > My biggest problem is the DDDS stuff (section 3). There is no > discussion of what domain you query the DNS for. This is an area well > worked over by other emergency stuff, and 'fragile' because what you > normally want is your "local" (as in access network) domain, and it's I don't think that's really true in general. Why should my access network have better information about these services, particularly if it has no interest in VoIP or emergency calls? I suspect that, initially, the service lookup will be offered by the VSP. They have an interest and obligation to provide the service and can't wait until every last ISP has decided to provide a mapping service. > not all that easy to determine what that is. Read the HELD and LCP > documents, and the discussion about this point. I think this document > needs to handle this. I think whatever it says is likely to have > to be > I didn't see any description of this in draft-winterbottom-geopriv- held-sighting-00. LCP seems to define, besides the usual suspects of manual configuration and DHCP, a broadcast request, not specified further. (This would be essentially a one-off version of SLP.) I think there are at least two plausible approaches to find an ISP- operated domain name, besides DHCP: (1) SLP or Bonjour; the practical problem is that SLP is seeing limited new deployments and Bonjour seems to be under the cloud of being non-IETF-developed (but comparatively widely deployed), with the IETF competitor having been sent back to the WG for a do-over (somebody might know more about this). (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain name (via the usual reverse DNS lookup); use SRV or NAPTR record for that domain. This relies on the user's public IP address having a DNS entry. As far as I can tell, this seems to be almost universally true for residential broadband. (For enterprise users, I suspect that the DHCP solution is easiest.) I had suggested a version of (2). > the same as any other similar mechanism in the milieu (for example, > how > you find your LoST server). We need to decide what this text is, and > copy it into all the relevant documents. Actually, you find your LoST server via this mechanism, since it performs the translation. > > I am confused by the "Validation Mechanism" in Section 2. First of > all > the word "resource" is used here for the first time. I am assuming it > has the meaning of 3406 resource. The real problem is that the > section > in 3406 that talks about validity defines it as "is there a valid > service" rather than "is the service available". Using the DDDS > mechanism would only tell you if a service was available (in the sense > of configured, rather than in the sense of functioning) within a > domain. > While I think you could keep most of this text if you qualify it, I > think the actual answer is that the validation mechanism is IANA > assignment. I agree that this doesn't quite fit; I reread 3406 and 3406 defines validation thusly: Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN.=20 [...] This seems to imply that this mechanism would allow to determine whether urn:service:timezone, say, exists or not. This would presumably be done by the lookup mechanism. I'll reword the paragraph to hopefully make the distinction clearer. (more to follow) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 12 09:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfE3-0000DT-6e; Wed, 12 Apr 2006 09:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfE1-0000BG-Qq for enum@ietf.org; Wed, 12 Apr 2006 09:17:37 -0400 Received: from fw-d-whp.denic.de ([81.91.160.27] helo=denic.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTfE1-0005CB-HA for enum@ietf.org; Wed, 12 Apr 2006 09:17:37 -0400 Received: by unknown.office.denic.de (Postfix, from userid 501) id 0DB092A5FB2; Wed, 12 Apr 2006 15:17:35 +0200 (CEST) Date: Wed, 12 Apr 2006 15:17:35 +0200 From: Peter Koch To: IETF ENUM WG Subject: Re: [Enum] ENUM Working Group Last call on ENUM Implementation Experiences Message-ID: <20060412131735.GC1892@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <442A9BC1.7090606@shockey.us> <20060411182031.GD1162@unknown.office.denic.de> <56EEA54D-0F24-40E4-9730-E6DABF914FA7@rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56EEA54D-0F24-40E4-9730-E6DABF914FA7@rfc1035.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Jim, On Tue, Apr 11, 2006 at 08:40:52PM +0100, Jim Reid wrote: > First off, even a modest NAPTR RRset will comfortably exceed a 512 > byte payload. My ENUM zone (3.2.5.2.5.8.8.9.6.1.4.4.e164.arpa) > contains 6 NAPTR RRs. Which is on the low side for reasonable usage. just as a data point, not to argue about the 'reasonable' size: under +49 the average number of NAPTRs in an RRSet is a little above 2, with very few going beyond 5 and the largest having 14 NAPTR RRs. > etc, etc. This lookup gets a 507 byte response. And that's with > dropping potentially useful data from the Additional Section as well > as optimal label compression. With EDNS0, the Additional Section Compression is mandatory and there's not much useful in the additional section in this case, given today's anti-poisoning measures. > isn't "truncated" and the full response is 602 bytes. No doubt there's a gain (for size, no real one here) with EDNS0 and we are in violent agreement that EDNS0 is just 'state of the art' (more precisely: EDNS0 _and_ reasonable buffer size). > draft says "All servers involved in ENUM resolution". The client > doing the lookup or the server resolving that ENUM lookup does not > have a priori knowledge of the size of the target zone's NAPTR RRset. There are servers 'involved in ENUM resolution' that don't even serve NAPTR RRSets and depending on your setup you might be able to know how large NAPTR responses will grow. Again agreed, i do not think aiming at 512 is reasonable in the latter case. > Mandating EDNS0 with good buffer sizes is not only essential and > prudent, it's just an application of the "be liberal in what you > receive" principle. Supporting EDNS0 is just good practice, but the arguments did not support the claim. Anyway, how can i argue against a non-normative 'MUST'? > Even at 6 NAPTRs -- which is by no means XXL sized -- using EDNS0 is Sorry for being lazy w.r.t. "XXL" -- i meant that to indicate an RRSet bringing the response > 512 octets. > to get the data that could/should have been in the Additional > Section. That extra latency is bad news, especially on things like > GPRS networks. Cool, tell that the low TTL advocates. The additional section doesn't solve the problem, though. > We will have to sort this out over a few beers at RIPE52. :-) That sounds intersting enough to postpone further detailed discussion :-) -Peter _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 13 06:43:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTzIK-0002Eu-2w; Thu, 13 Apr 2006 06:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTzII-0002EC-Ua for enum@ietf.org; Thu, 13 Apr 2006 06:43:22 -0400 Received: from substance.cnnic.cn ([159.226.7.145] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTzI5-0007vI-NM for enum@ietf.org; Thu, 13 Apr 2006 06:43:18 -0400 Received: (eyou send program); Thu, 13 Apr 2006 18:42:41 +0800 Message-ID: <344924961.28912@cnnic.cn> X-EYOUMAIL-SMTPAUTH: chenhui@cnnic.cn Received: from unknown (HELO cnnicchenh) (159.226.6.99) by 159.226.7.145 with SMTP; Thu, 13 Apr 2006 18:42:41 +0800 Message-ID: <009601c65ee7$01e096b0$6306e29f@cnnicchenh> From: "chenhui" To: Date: Thu, 13 Apr 2006 18:42:48 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.3 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: =?gb2312?B?J831ILflJw==?= Subject: [Enum] Some open source ENUM correlative softwares X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2104446169==" Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============2104446169== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0093_01C65F2A.0FD8F620" This is a multi-part message in MIME format. ------=_NextPart_000_0093_01C65F2A.0FD8F620 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciAgY29sbGVhZ3VlcywNCg0KQ05OSUMgIGhhcyAgZGV2ZWxvcGVkICBzb21lICBFTlVNICBj b3JyZWxhdGl2ZSAgc29mdHdhcmVzLg0KSW4gIG9yZGVyICB0byAgZmFjaWxpdGF0ZSAgdGhlICBk ZXZlbG9wbWVudCAgb2YgIG11bHRpZmFyaW91cyAgRU5VTSAgYXBwbGljYXRpb25zLCAgbm93ICB3 ZSAgcHVibGlzaCAgdGhlICBvcGVuICBzb3VyY2UgIHNvZnR3YXJlICJFTlVNTG9va3VwIiAgYW5k ICAiRmlyZWZveCAgdG9vbGJhciIsICB3aGljaCAgY2FuICBiZSAgY29waWVkIC8gcmVkZXZlbG9w ZWQgLyBjaGFuZ2VkIC8gZW1iZWRkZWQgIGluICBvdGhlciAgaGFyZHdhcmUgIGFuZCAgc29mdHdh cmUuDQoNCiJFTlVNTG9va3VwIiBoYXMgdHdvIGltcGxlbWVudGF0aW9ucywgbWFpbmx5IGFzIEVO VU0gUmVzb2x2ZXIsIG9uZSAgaXMgIGZvciAgV2luZG93cyAgc3lzdGVtLCAgdGhlICBvdGhlciAg aXMgIGZvciBMaW51eCAgc3lzdGVtLiBBcyAgd2Uga25vdywgIEVOVU0gIHVzZXMgIE5BUFRSICBm b3JtYXQgIHRvICBzdG9yZSAgRU5VTSAgcmVjb3JkcyAgaW4gIEROUyAgem9uZSAgZmlsZSwgIGJ1 dCAgd2luZG93cyAgc3lzdGVtICBjYW4ndCBkaXJlY3RseSAgc3VwcG9ydCAgRE5TICBOQVBUUiBy ZWNvcmRzLiAgIldpbmRvd3MgRU5VTUxvb2t1cCIgIHNvZnR3YXJlICBsaWtlcyAgdGhlICBmdW5j dGlvbiAgb2YgICJuc2xvb2t1cCIgIGluICBET1MgIGNvbW1hbmRzLCAgYW5kICB0aGVuICB3aW5k b3dzICBzeXN0ZW0gY2FuIHJlY2VpdmUgRU5VTSAgTkFQVFIgIHJlY29yZHMuICAiTGludXggRU5V TUxvb2t1cCIgIHNvZnR3YXJlICBkcmF3cyAgb3V0ICB0aGUgIGluZGVwZW5kZW50ICBFTlVNICBx dWVyeSAgZnVuY3Rpb24gIGFuZCAgY2FuICBiZSAgZWFzaWx5IGludGVncmF0ZWQgIGluICBvdGhl ciAgYXBwbGljYXRpb24gIHN5c3RlbS4NCg0KIkVOVU1Mb29rdXAiICBzdXBwb3J0cyAgUkZDMzc2 MSwgIGFuZCAgY2FuICBkaXNwbGF5ICBhbGwgIHRoZSAgRU5VTSAgcmVjb3JkcyAgaW4gIE9SREVS ICBhbmQgIFBSSU9SSVRZLiAgQWxzbywgIGl0ICBjYW4gIGJlICBjb25maWd1cmVkICB0byBmaWx0 ZXIgIHRoZSAgc3BlY2lhbCAgdHlwZS9zdWJ0eXBlICBFTlVNICBzZXJ2aWNlLg0KDQoiRmlyZWZv eCAgdG9vbGJhciIgIGlzICBhbiAgRXh0ZW5zaW9uICBmb3IgIFdpbmRvd3MgIEZpcmVmb3ggIDEu MCAgYW5kICBXaW5kb3dzICBGaXJlZm94ICAxLjUrLiAgSXQgIGNhbiAgcHJvY2VzcyAgRU5VTSAg UXVlcnkgIGJ5IGlucHV0dGluZyBFTlVNICBudW1iZXIgIHdoaWNoICBoYXMgIHJlZ2lzdGVyZWQg IGluICB0aGUgIGUxNjQuYXJwYSAgZG9tYWluICBhbmQgIGRpc3BsYXkgIHRoZSAgcmVsYXRpdmUg IEVOVU0gIHJlc291cmNlICByZWNvcmRzICBvbiAgYSAgaHRtbCAgZmlsZS4gQWNjb3JkaW5nICB0 byAgdGhlICBkaWZmZXJlbnQgIEVOVU0gIHNlcnZpY2VzLCAgaXQgIGNhbiAgYWxzbyAgZGlyZWN0 bHkgIGxpbmsgIHRoZSAgaGlnaGVzdCAgcHJpb3JpdHkgIHdlYnBhZ2UgIG9yICBzZW5kICBFbWFp bCAgdG8gIHRoZSBoaWdoZXN0ICBwcmlvcml0eSAgZW1haWwgIGFkZHJlc3MgIGV0Yy4NCg0KUGxl YXNlICByZWZlciAgdG8gIHRoZSAgYmVsb3cgIGxpbms6DQpodHRwOi8vd3d3LmVudW0uY24vRW51 bS9FbnVtUmVnL0VudW1CYXIvT3Blbi1zb3VyY2UvDQoNCldlbGNvbWUgIHRvICB0ZXN0ICBhbmQg IHVzZSwgYW55IHN1Z2dlc3Rpb24gd2lsbCBoZWxwIG91ciBpbXByb3ZpbmcgRU5VTSBpbXBsZW1l bnRhdGlvbnMuICBJZiAgYW55ICBwcm9ibGVtLCAgUGxlYXNlICBzZW5kICBtYWlsICB0byBlbnVt QGNubmljLmNuLiANCkxldCdzICBwZXJmZWN0ICB0aGUgIEVOVU0gIHNvZnR3YXJlLCAgYW5kICBw cm9tb3RlICB0aGUgIHByb2dyZXNzICBvZiAgRU5VTS4NCg0KQ2hlbmh1aQ== ------=_NextPart_000_0093_01C65F2A.0FD8F620 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI4NzMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9y87M5SBzaXplPTI+RGVhciAm bmJzcDtjb2xsZWFndWVzLDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Q05OSUMgJm5i c3A7aGFzICZuYnNwO2RldmVsb3BlZCAmbmJzcDtzb21lICZuYnNwO0VOVU0gJm5ic3A7Y29ycmVs YXRpdmUgDQombmJzcDtzb2Z0d2FyZXMuPC9ESVY+DQo8RElWPkluICZuYnNwO29yZGVyICZuYnNw O3RvICZuYnNwO2ZhY2lsaXRhdGUgJm5ic3A7dGhlICZuYnNwO2RldmVsb3BtZW50IA0KJm5ic3A7 b2YgJm5ic3A7bXVsdGlmYXJpb3VzICZuYnNwO0VOVU0gJm5ic3A7YXBwbGljYXRpb25zLCAmbmJz cDtub3cgJm5ic3A7d2UgDQombmJzcDtwdWJsaXNoICZuYnNwO3RoZSAmbmJzcDtvcGVuICZuYnNw O3NvdXJjZSAmbmJzcDtzb2Z0d2FyZSAiRU5VTUxvb2t1cCIgDQombmJzcDthbmQmbmJzcDsmbmJz cDsiRmlyZWZveCAmbmJzcDt0b29sYmFyIiwgJm5ic3A7d2hpY2ggJm5ic3A7Y2FuICZuYnNwO2Jl IA0KJm5ic3A7Y29waWVkJm5ic3A7LyByZWRldmVsb3BlZCZuYnNwOy8gY2hhbmdlZCAvIGVtYmVk ZGVkICZuYnNwO2luICZuYnNwO290aGVyIA0KJm5ic3A7aGFyZHdhcmUgJm5ic3A7YW5kICZuYnNw O3NvZnR3YXJlLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+IkVOVU1Mb29rdXAiIGhh cyB0d28gaW1wbGVtZW50YXRpb25zLCBtYWlubHkgYXMgRU5VTSBSZXNvbHZlciwgb25lJm5ic3A7 IA0KaXMmbmJzcDsgZm9yICZuYnNwO1dpbmRvd3MgJm5ic3A7c3lzdGVtLCAmbmJzcDt0aGUgJm5i c3A7b3RoZXIgJm5ic3A7aXMgDQombmJzcDtmb3IgTGludXggJm5ic3A7c3lzdGVtLiBBcyAmbmJz cDt3ZSBrbm93LCAmbmJzcDtFTlVNICZuYnNwO3VzZXMgDQombmJzcDtOQVBUUiAmbmJzcDtmb3Jt YXQgJm5ic3A7dG8gJm5ic3A7c3RvcmUgJm5ic3A7RU5VTSAmbmJzcDtyZWNvcmRzICZuYnNwO2lu IA0KJm5ic3A7RE5TICZuYnNwO3pvbmUgJm5ic3A7ZmlsZSwgJm5ic3A7YnV0ICZuYnNwO3dpbmRv d3MgJm5ic3A7c3lzdGVtIA0KJm5ic3A7Y2FuJ3QgZGlyZWN0bHkmbmJzcDsmbmJzcDtzdXBwb3J0 ICZuYnNwO0ROUyAmbmJzcDtOQVBUUiByZWNvcmRzLiANCiZuYnNwOyJXaW5kb3dzJm5ic3A7RU5V TUxvb2t1cCIgJm5ic3A7c29mdHdhcmUmbmJzcDsmbmJzcDtsaWtlcyAmbmJzcDt0aGUgDQombmJz cDtmdW5jdGlvbiAmbmJzcDtvZiAmbmJzcDsibnNsb29rdXAiICZuYnNwO2luICZuYnNwO0RPUyAm bmJzcDtjb21tYW5kcywgDQombmJzcDthbmQgJm5ic3A7dGhlbiAmbmJzcDt3aW5kb3dzICZuYnNw O3N5c3RlbSBjYW4mbmJzcDtyZWNlaXZlJm5ic3A7RU5VTSANCiZuYnNwO05BUFRSICZuYnNwO3Jl Y29yZHMuICZuYnNwOyJMaW51eCZuYnNwO0VOVU1Mb29rdXAiICZuYnNwO3NvZnR3YXJlIA0KJm5i c3A7ZHJhd3MgJm5ic3A7b3V0ICZuYnNwO3RoZSAmbmJzcDtpbmRlcGVuZGVudCAmbmJzcDtFTlVN ICZuYnNwO3F1ZXJ5IA0KJm5ic3A7ZnVuY3Rpb24gJm5ic3A7YW5kICZuYnNwO2NhbiAmbmJzcDti ZSAmbmJzcDtlYXNpbHkgaW50ZWdyYXRlZCAmbmJzcDtpbiANCiZuYnNwO290aGVyICZuYnNwO2Fw cGxpY2F0aW9uICZuYnNwO3N5c3RlbS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiJF TlVNTG9va3VwIiAmbmJzcDtzdXBwb3J0cyAmbmJzcDtSRkMzNzYxLCAmbmJzcDthbmQgJm5ic3A7 Y2FuIA0KJm5ic3A7ZGlzcGxheSAmbmJzcDthbGwgJm5ic3A7dGhlICZuYnNwO0VOVU0gJm5ic3A7 cmVjb3JkcyAmbmJzcDtpbiAmbmJzcDtPUkRFUiANCiZuYnNwO2FuZCAmbmJzcDtQUklPUklUWS4g Jm5ic3A7QWxzbywgJm5ic3A7aXQgJm5ic3A7Y2FuICZuYnNwO2JlIA0KJm5ic3A7Y29uZmlndXJl ZCAmbmJzcDt0byBmaWx0ZXIgJm5ic3A7dGhlJm5ic3A7Jm5ic3A7c3BlY2lhbCAmbmJzcDt0eXBl L3N1YnR5cGUgDQombmJzcDtFTlVNICZuYnNwO3NlcnZpY2UuPC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj4iRmlyZWZveCAmbmJzcDt0b29sYmFyIiAmbmJzcDtpcyAmbmJzcDthbiAmbmJz cDtFeHRlbnNpb24gJm5ic3A7Zm9yIA0KJm5ic3A7V2luZG93cyAmbmJzcDtGaXJlZm94ICZuYnNw OzEuMCAmbmJzcDthbmQgJm5ic3A7V2luZG93cyAmbmJzcDtGaXJlZm94IA0KJm5ic3A7MS41Ky4g Jm5ic3A7SXQgJm5ic3A7Y2FuICZuYnNwO3Byb2Nlc3MgJm5ic3A7RU5VTSAmbmJzcDtRdWVyeSAm bmJzcDtieSANCmlucHV0dGluZyBFTlVNICZuYnNwO251bWJlciZuYnNwOyZuYnNwO3doaWNoICZu YnNwO2hhcyAmbmJzcDtyZWdpc3RlcmVkICZuYnNwO2luIA0KJm5ic3A7dGhlICZuYnNwO2UxNjQu YXJwYSAmbmJzcDtkb21haW4gJm5ic3A7YW5kICZuYnNwO2Rpc3BsYXkgJm5ic3A7dGhlIA0KJm5i c3A7cmVsYXRpdmUgJm5ic3A7RU5VTSAmbmJzcDtyZXNvdXJjZSAmbmJzcDtyZWNvcmRzICZuYnNw O29uICZuYnNwO2EgDQombmJzcDtodG1sICZuYnNwO2ZpbGUuIEFjY29yZGluZyAmbmJzcDt0byAm bmJzcDt0aGUgJm5ic3A7ZGlmZmVyZW50IA0KJm5ic3A7RU5VTSZuYnNwOyZuYnNwO3NlcnZpY2Vz LCAmbmJzcDtpdCAmbmJzcDtjYW4gJm5ic3A7YWxzbyAmbmJzcDtkaXJlY3RseSANCiZuYnNwO2xp bmsgJm5ic3A7dGhlICZuYnNwO2hpZ2hlc3QgJm5ic3A7cHJpb3JpdHkgJm5ic3A7d2VicGFnZSAm bmJzcDtvciANCiZuYnNwO3NlbmQgJm5ic3A7RW1haWwgJm5ic3A7dG8gJm5ic3A7dGhlIGhpZ2hl c3QgJm5ic3A7cHJpb3JpdHkgJm5ic3A7ZW1haWwgDQombmJzcDthZGRyZXNzICZuYnNwO2V0Yy48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlBsZWFzZSAmbmJzcDtyZWZlciAmbmJzcDt0 byAmbmJzcDt0aGUgJm5ic3A7YmVsb3cgJm5ic3A7bGluazo8L0RJVj4NCjxESVY+PEEgDQpocmVm PSJodHRwOi8vd3d3LmVudW0uY24vRW51bS9FbnVtUmVnL0VudW1CYXIvT3Blbi1zb3VyY2UvIj5o dHRwOi8vd3d3LmVudW0uY24vRW51bS9FbnVtUmVnL0VudW1CYXIvT3Blbi1zb3VyY2UvPC9BPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+V2VsY29tZSAmbmJzcDt0byAmbmJzcDt0ZXN0 ICZuYnNwO2FuZCAmbmJzcDt1c2UsIGFueSBzdWdnZXN0aW9uIHdpbGwgaGVscCANCm91ciBpbXBy b3ZpbmcgRU5VTSZuYnNwO2ltcGxlbWVudGF0aW9ucy4gJm5ic3A7SWYgJm5ic3A7YW55ICZuYnNw O3Byb2JsZW0sIA0KJm5ic3A7UGxlYXNlICZuYnNwO3NlbmQgJm5ic3A7bWFpbCAmbmJzcDt0byA8 QSANCmhyZWY9Im1haWx0bzplbnVtQGNubmljLmNuIj5lbnVtQGNubmljLmNuPC9BPi4gPC9ESVY+ DQo8RElWPkxldCdzICZuYnNwO3BlcmZlY3QgJm5ic3A7dGhlICZuYnNwO0VOVU0gJm5ic3A7c29m dHdhcmUsICZuYnNwO2FuZCANCiZuYnNwO3Byb21vdGUgJm5ic3A7dGhlICZuYnNwO3Byb2dyZXNz ICZuYnNwO29mICZuYnNwO0VOVU0uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5DaGVu aHVpPC9ESVY+PC9GT05UPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0093_01C65F2A.0FD8F620-- --===============2104446169== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============2104446169==-- From enum-bounces@ietf.org Thu Apr 13 10:18:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2dz-0005r8-A9; Thu, 13 Apr 2006 10:17:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgVa-00036T-9P; Wed, 12 Apr 2006 10:39:50 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTgVZ-00081g-T6; Wed, 12 Apr 2006 10:39:50 -0400 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k3CEdXcL006610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Apr 2006 10:39:47 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k3CEdH28003334; Wed, 12 Apr 2006 10:39:31 -0400 Message-ID: <443D111B.7010100@cs.columbia.edu> Date: Wed, 12 Apr 2006 10:39:23 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard References: <32755D354E6B65498C3BD9FD496C7D462C4984@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4984@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_REFNUM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.5 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc X-Mailman-Approved-At: Thu, 13 Apr 2006 10:17:58 -0400 Cc: enum@ietf.org, "Rosen, Brian" , ecrit@ietf.org Subject: [Enum] Re: URNs in ENUM (Laywer) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Stastny Richard wrote: > Hmm, > > This could be done. OTOH, do all URN:service resolve with LoST No; each top-level service (sos, lawyer, etc.) could decide to use a different protocol. Whether all these layers of indirection are necessary and helpful is another question... > > This seems a bit a chicken-and-egg problem > if a user enters a service URN direct, there must be a way to resolve it > within e.g. SIP > anyway, so why burden ENUM resolvers with service resolving > do it one after the other ENUM - SIP - LoST-SIP > > especially if the UA is not capable of doing LoST > so the service URN has to be forwarded to the proxy anyway via SIP > > Richard > > ________________________________ > > Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Gesendet: Di 11.04.2006 17:53 > An: Stastny Richard; Henning Schulzrinne; enum@ietf.org > Cc: ecrit@ietf.org > Betreff: RE: URNs in ENUM (Laywer) > > > > Richard > > Read what I wrote. > > The enum dip would return urn:service.lawyer > You would use LoST (not SIP) to resolve it > That would resolve to a sip uri > > I think that's a LoST enumservice, right? > > Brian > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 11, 2006 9:50 AM > To: Rosen, Brian; Henning Schulzrinne; enum@ietf.org > Cc: ecrit@ietf.org > Subject: URNs in ENUM (Laywer) > >> Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 >> telephone number. To make this work using service urns, you would have >> to have the result of an enum dip for this number result in a urn that >> is not currently a valid enum service. However, if you did make a new >> service, it would work: > > Thank you for bringing this forward, I will crosspost this question to > the ENUM WG > > I am not really sure if you need an new Enumservice at all > > It depends if a service URN is a valid entry in a SIP URI > > If it is you do not even need a a new Enumservice to make this work, > the "sip" Enumservice would be sufficient > > The real problem here is again to locate the LoST service database > > any comments here frem ENUM WG? > > Richard > > > ________________________________ > > Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Gesendet: Mo 10.04.2006 20:24 > An: Henning Schulzrinne > Cc: ecrit@ietf.org > Betreff: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02 > > > > Re: 1-800-LAWYER. The number you gave (1-800-Lawyer) is an e.164 > telephone number. To make this work using service urns, you would have > to have the result of an enum dip for this number result in a urn that > is not currently a valid enum service. However, if you did make a new > service, it would work: > > e.164 is looked up in enum > result is service urn > urn is mapped with LoST > call is sent where indicated, based on location of caller. > > Now, the caller would have to voluntarily put location on the call for > this to work. > > I read: > Apart from attempting resolution of a URN, a URN namespace may > provide mechanisms for "validating" a URN -- i.e., determining > whether a given string is currently a validly-assigned URN. > > quite literally. urn:service.sos is a validly-assigned URN because > there is an RFC that says it is (which is the same as saying it's in the > IANA registry of services). "Validly-assigned" does not mean "currently > active in a domain" to me. > > Brian > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, April 09, 2006 9:23 PM > To: Rosen, Brian > Cc: ecrit@ietf.org > Subject: Re: Review of draft-ietf-ecrit-service-urn-02 > > More responses: > > On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote: > >> I have reviewed service-urn-02 and have the following comments: >> >> A little concerned about 1-800-LAWYER as an example. The problem here >> is that there is no obvious mechanism to translate the e.164 >> 1-800-LAWYER to the service urn. I suppose someone could propose an >> enumservice for this purpose, but until they do, we might consider >> removing this particular example > > Removing lawyers is always a good idea. (The similarity is that > dialing this number will get you a lawyer anywhere in the US, with > the law office depending on where you're calling from.) I don't quite > understand your concern about needing an enum service. > >> You need a statement that points out the obvious: since the service >> urn >> is a protocol labeling mechanism, it has no i18n implications. > > I'll add an I18N section. > >> My biggest problem is the DDDS stuff (section 3). There is no >> discussion of what domain you query the DNS for. This is an area well >> worked over by other emergency stuff, and 'fragile' because what you >> normally want is your "local" (as in access network) domain, and it's > > I don't think that's really true in general. Why should my access > network have better information about these services, particularly if > it has no interest in VoIP or emergency calls? I suspect that, > initially, the service lookup will be offered by the VSP. They have > an interest and obligation to provide the service and can't wait > until every last ISP has decided to provide a mapping service. > > >> not all that easy to determine what that is. Read the HELD and LCP >> documents, and the discussion about this point. I think this document >> needs to handle this. I think whatever it says is likely to have >> to be >> > > I didn't see any description of this in draft-winterbottom-geopriv- > held-sighting-00. LCP seems to define, besides the usual suspects of > manual configuration and DHCP, a broadcast request, not specified > further. (This would be essentially a one-off version of SLP.) > > I think there are at least two plausible approaches to find an ISP- > operated domain name, besides DHCP: > > (1) SLP or Bonjour; the practical problem is that SLP is seeing > limited new deployments and Bonjour seems to be under the cloud of > being non-IETF-developed (but comparatively widely deployed), with > the IETF competitor having been sent back to the WG for a do-over > (somebody might know more about this). > > (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain > name (via the usual reverse DNS lookup); use SRV or NAPTR record for > that domain. This relies on the user's public IP address having a DNS > entry. As far as I can tell, this seems to be almost universally true > for residential broadband. (For enterprise users, I suspect that the > DHCP solution is easiest.) > > I had suggested a version of (2). > > >> the same as any other similar mechanism in the milieu (for example, >> how >> you find your LoST server). We need to decide what this text is, and >> copy it into all the relevant documents. > > Actually, you find your LoST server via this mechanism, since it > performs the translation. > > >> I am confused by the "Validation Mechanism" in Section 2. First of >> all >> the word "resource" is used here for the first time. I am assuming it >> has the meaning of 3406 resource. The real problem is that the >> section >> in 3406 that talks about validity defines it as "is there a valid >> service" rather than "is the service available". Using the DDDS >> mechanism would only tell you if a service was available (in the sense >> of configured, rather than in the sense of functioning) within a >> domain. >> While I think you could keep most of this text if you qualify it, I >> think the actual answer is that the validation mechanism is IANA >> assignment. > > I agree that this doesn't quite fit; I reread 3406 and 3406 defines > validation thusly: > > Apart from attempting resolution of a URN, a URN namespace may > provide mechanisms for "validating" a URN -- i.e., determining > whether a given string is currently a validly-assigned URN. > [...] > > This seems to imply that this mechanism would allow to determine > whether urn:service:timezone, say, exists or not. This would > presumably be done by the lookup mechanism. > > I'll reword the paragraph to hopefully make the distinction clearer. > > (more to follow) > > Henning > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 13 17:03:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8xM-0008EV-DE; Thu, 13 Apr 2006 17:02:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8xL-0008EP-L8 for enum@ietf.org; Thu, 13 Apr 2006 17:02:23 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FU8xK-0003ad-72 for enum@ietf.org; Thu, 13 Apr 2006 17:02:23 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-15.tower-121.messagelabs.com!1144962075!8515148!13 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6922 invoked from network); 13 Apr 2006 21:02:21 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-15.tower-121.messagelabs.com with SMTP; 13 Apr 2006 21:02:21 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 441D8F75003E9475; Thu, 13 Apr 2006 17:02:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] ENUM Working Group Last call on InfrastructureENUMRequirements Date: Thu, 13 Apr 2006 17:02:14 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C934207@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <1050E7CDAF4ED042BA2096CC187A79A7027D11A9@safir.pts.ad> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] ENUM Working Group Last call on InfrastructureENUMRequirements Thread-Index: AcZQcYY1Lqj+drJZRKWTY638iXz49wM4CrTgAHnkQIA= From: "Pfautz, Penn L, NEO" To: , , X-Spam-Score: 0.5 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: fluffy@cisco.com, tsg2q1@itu.int, paf@cisco.com, jon.peterson@neustar.biz X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Joakim: Thanks for your comments. Let me see if I can begin to address them = in-line below. Penn=20 -----Original Message----- From: Joakim.Stralmark@pts.se [mailto:Joakim.Stralmark@pts.se]=20 Sent: Tuesday, April 11, 2006 7:06 AM To: richard@shockey.us; enum@ietf.org Cc: fluffy@cisco.com; =3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr?=3D; = paf@cisco.com; jon.peterson@neustar.biz; tsg2q1@itu.int Subject: SV: [Enum] ENUM Working Group Last call on = InfrastructureENUMRequirements HELLO We have some small comments on the I-D that now is on last call. Our comments follow the present structure of the ID. Clause 1.1 The second paragraph of 1.1 could be updated so E.164-number for mobile = service are included - see example below: The "carrier of record" will typically be a service provider authorized = to issue E.164 numbers for the provisioning of fixed (PSTN/ISDN) and = mobile (PLMN) communication services under the authority of a National = Regulatory Authority (NRA), but generally exhibits one or more of the = following properties: >> We had intended "PSTN" to cover both fixed and mobile E.164 numbers. = I don't mind=20 >> calling out PLMN as well if you feel that would be clearer. We are not so familiar with term "carrier of record" and the last = paragraph in 1.1 states that NRA shall ultimately determine this. We = think this I-D needs to define "carrier of records" and exactly explain = its meaning. The paragraph above gives the impression that the term is a = term of an SP (service provider). >> My preference would have been to say that the Carrier of Record is = the entity that=20 >> provides the PSTN/PLMN point of interface for other carriers to = deliver calls to.=20 >> This can become complicated in situations where there is number = portability without a >> central number portability database or where resale is involved. What = entity should >> be the CoR in these cases might be argued, which is why we said the = NRA may have to=20 >> decide. There may also cases where there may be no PSTN PoI. In the = US >> we can easily operationalize the definition of CoR based on the = industry routing >> databases (LERG and NPAC), but, in trying to be general we wound up = with the more=20 >> provisional definition you currently see in the I-D.=20 Clause 1.2 Is it correct understanding that the "infrastructure ENUM namespace" = could be in the .e164.apra used for User ENUM or in another public tree, = but should it only be in ONE or in many public trees? >>It should only be in one place. While the doing something in e164.arpa = (e.g.,=20 >>c.e164.arpa or even non-terminal NAPTR records has not been ruled = out), I think it most >> likely that infrastructure apex would be something else under .arpa = e.g., ie164.arpa. Later in this paragraph we think it is appropriate to delete the term = "closed" before NGN and also add mobile networks, i.e. PLMN. >>our point here was to indicate that the destination might not be part = of the Internet Clause 2 In 6) - we think "PLMN applications" could be added. In 7) the meaning of "discovery of unlisted numbers" is unclear and = might further description. >>Our concern here was prompted by that of US regulators who worry that, = if only >> active numbers are listed in infrastructure ENUM, unscrupulous = parties could compare >> infrastructure ENUM registrations against directory listings and thus = identify >> numbers in ENUM w/o corresponding directory listings to be unlisted = numbers >> and launch telemarketing calls.=20 In 8) B) only "open numbering plan" are mentioned but we hope the I-D = also cover "closed numbering plan". >>We intend to cover closed as well. Open plans are specifically cited = because they raise >> issues for certain potential solutions (i.e., non-terminal NAPTRs). = We'll change this >> to read "open as well as closed" In 8 F) and G) the terms "end-user ENUM" and "private ENUM" are used - = this terms, together with User ENUM and infrastructure ENUM could be = defined in this I-D/RFC. Clause 3 The statements in the second paragraph about register all allocated = number to avoid identification of unlisted numbers is a little bit = unclear - please explain this better in the I-D/RFC Clause 5 The I-D author could correct the version number of [3] of ITU-T = Recommendation E.164 as he also is the editor of E.164. Sincerely Joakim Str=E5lmark Swedish Administration/NRA Tel. +46 70 811 40 64=20 -----Ursprungligt meddelande----- Fr=E5n: Richard Shockey [mailto:richard@shockey.us]=20 Skickat: den 25 mars 2006 21:52 Till: enum@ietf.org Kopia: Cullen Jennings; =3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr?=3D; =F6m; = Peterson,Jon =C4mne: [Enum] ENUM Working Group Last call on Infrastructure = ENUMRequirements Title : Infrastructure ENUM Requirements Author(s) : S. Lind, P. Pfautz Filename : draft-ietf-enum-infrastructure-enum-reqs-01.txt Pages : 8 Date : 2006-3-23 =09 This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-r= eqs-01.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. This document has been under extensive discussion since early 2005. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 3 weeks or so from Monday Mar 27 until at least April 17 though we can modify that if new issues come up. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 17 13:32:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXZu-0001fP-2i; Mon, 17 Apr 2006 13:31:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXZs-0001fK-D7 for enum@ietf.org; Mon, 17 Apr 2006 13:31:56 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVXZr-0002QB-Vh for enum@ietf.org; Mon, 17 Apr 2006 13:31:56 -0400 Received: from [10.31.13.171] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k3HHWH66013365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Apr 2006 10:32:18 -0700 Message-ID: <4443D106.2050504@shockey.us> Date: Mon, 17 Apr 2006 13:31:50 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: IETF ENUM WG , pk@DENIC.DE Subject: Re: [Enum] ENUM Working Group Last call on ENUM Implementation Experiences References: <442A9BC1.7090606@shockey.us> <20060411182031.GD1162@unknown.office.denic.de> <56EEA54D-0F24-40E4-9730-E6DABF914FA7@rfc1035.com> <20060412131735.GC1892@unknown.office.denic.de> In-Reply-To: <20060412131735.GC1892@unknown.office.denic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Peter Koch wrote: > Jim, > > On Tue, Apr 11, 2006 at 08:40:52PM +0100, Jim Reid wrote: The document is in last call ..its still not clear to me what changes, if any you are suggesting. > >> First off, even a modest NAPTR RRset will comfortably exceed a 512 >> byte payload. My ENUM zone (3.2.5.2.5.8.8.9.6.1.4.4.e164.arpa) >> contains 6 NAPTR RRs. Which is on the low side for reasonable usage. > > just as a data point, not to argue about the 'reasonable' size: under +49 > the average number of NAPTRs in an RRSet is a little above 2, with very few > going beyond 5 and the largest having 14 NAPTR RRs. > >> etc, etc. This lookup gets a 507 byte response. And that's with >> dropping potentially useful data from the Additional Section as well >> as optimal label compression. With EDNS0, the Additional Section > > Compression is mandatory and there's not much useful in the additional > section in this case, given today's anti-poisoning measures. > >> isn't "truncated" and the full response is 602 bytes. > > No doubt there's a gain (for size, no real one here) with EDNS0 and we are > in violent agreement that EDNS0 is just 'state of the art' (more precisely: > EDNS0 _and_ reasonable buffer size). > >> draft says "All servers involved in ENUM resolution". The client >> doing the lookup or the server resolving that ENUM lookup does not >> have a priori knowledge of the size of the target zone's NAPTR RRset. > > There are servers 'involved in ENUM resolution' that don't even serve NAPTR > RRSets and depending on your setup you might be able to know how large NAPTR > responses will grow. Again agreed, i do not think aiming at 512 is reasonable > in the latter case. > >> Mandating EDNS0 with good buffer sizes is not only essential and >> prudent, it's just an application of the "be liberal in what you >> receive" principle. > > Supporting EDNS0 is just good practice, but the arguments did not support > the claim. Anyway, how can i argue against a non-normative 'MUST'? > >> Even at 6 NAPTRs -- which is by no means XXL sized -- using EDNS0 is > > Sorry for being lazy w.r.t. "XXL" -- i meant that to indicate an RRSet > bringing the response > 512 octets. > >> to get the data that could/should have been in the Additional >> Section. That extra latency is bad news, especially on things like >> GPRS networks. > > Cool, tell that the low TTL advocates. The additional section doesn't > solve the problem, though. > >> We will have to sort this out over a few beers at RIPE52. :-) > > That sounds intersting enough to postpone further detailed discussion :-) > > -Peter > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 17 13:35:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXdJ-0003Zp-6f; Mon, 17 Apr 2006 13:35:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXdH-0003Za-Bp for enum@ietf.org; Mon, 17 Apr 2006 13:35:27 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVXdG-0002iv-PE for enum@ietf.org; Mon, 17 Apr 2006 13:35:27 -0400 Received: from [10.31.13.171] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k3HHYjdK013828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Apr 2006 10:34:46 -0700 Message-ID: <4443D19A.3010004@shockey.us> Date: Mon, 17 Apr 2006 13:34:18 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pfautz, Penn L, NEO" Subject: Re: [Enum] ENUM Working Group Last call on InfrastructureENUMRequirements References: <34DA635B184A644DA4588E260EC0A25A0C934207@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0C934207@ACCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id k3HHYjdK013828 X-Spam-Score: 0.5 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: enum@ietf.org, fluffy@cisco.com, jon.peterson@neustar.biz, Joakim.Stralmark@pts.se, tsg2q1@itu.int, paf@cisco.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Pfautz, Penn L, NEO wrote: > Joakim: > Thanks for your comments. Let me see if I can begin to address them in= -line below. >=20 > Penn=20 Penn ..I'm assuming you want to incorporate these remarks into a new vers= ion? That would not be a problem and we would not have to extend last call to=20 accommodate that. >=20 > -----Original Message----- > From: Joakim.Stralmark@pts.se [mailto:Joakim.Stralmark@pts.se]=20 > Sent: Tuesday, April 11, 2006 7:06 AM > To: richard@shockey.us; enum@ietf.org > Cc: fluffy@cisco.com; =3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr?=3D; paf@cisc= o.com; jon.peterson@neustar.biz; tsg2q1@itu.int > Subject: SV: [Enum] ENUM Working Group Last call on InfrastructureENUMR= equirements >=20 > HELLO > We have some small comments on the I-D that now is on last call. > Our comments follow the present structure of the ID. >=20 > Clause 1.1 > The second paragraph of 1.1 could be updated so E.164-number for mobile= service are included - see example below: > The "carrier of record" will typically be a service provider authorized= to issue E.164 numbers for the provisioning of fixed (PSTN/ISDN) and mob= ile (PLMN) communication services under the authority of a National Regul= atory Authority (NRA), but generally exhibits one or more of the followin= g properties: >>> We had intended "PSTN" to cover both fixed and mobile E.164 numbers. = I don't mind=20 >>> calling out PLMN as well if you feel that would be clearer. >=20 > We are not so familiar with term "carrier of record" and the last parag= raph in 1.1 states that NRA shall ultimately determine this. We think thi= s I-D needs to define "carrier of records" and exactly explain its meanin= g. The paragraph above gives the impression that the term is a term of an= SP (service provider). >=20 >>> My preference would have been to say that the Carrier of Record is t= he entity that=20 >>> provides the PSTN/PLMN point of interface for other carriers to deliv= er calls to.=20 >>> This can become complicated in situations where there is number porta= bility without a >>> central number portability database or where resale is involved. What= entity should >>> be the CoR in these cases might be argued, which is why we said the N= RA may have to=20 >>> decide. There may also cases where there may be no PSTN PoI. In the U= S >>> we can easily operationalize the definition of CoR based on the indus= try routing >>> databases (LERG and NPAC), but, in trying to be general we wound up w= ith the more=20 >>> provisional definition you currently see in the I-D.=20 >=20 > Clause 1.2 > Is it correct understanding that the "infrastructure ENUM namespace" co= uld be in the .e164.apra used for User ENUM or in another public tree, bu= t should it only be in ONE or in many public trees? >=20 >>> It should only be in one place. While the doing something in e164.arp= a (e.g.,=20 >>> c.e164.arpa or even non-terminal NAPTR records has not been ruled out= ), I think it most >>> likely that infrastructure apex would be something else under .arpa e= .g., ie164.arpa. >=20 > Later in this paragraph we think it is appropriate to delete the term "= closed" before NGN and also add mobile networks, i.e. PLMN. >=20 >>> our point here was to indicate that the destination might not be part= of the Internet >=20 > Clause 2 > In 6) - we think "PLMN applications" could be added. > In 7) the meaning of "discovery of unlisted numbers" is unclear and mig= ht further description. >>> Our concern here was prompted by that of US regulators who worry that= , if only >>> active numbers are listed in infrastructure ENUM, unscrupulous partie= s could compare >>> infrastructure ENUM registrations against directory listings and thus= identify >>> numbers in ENUM w/o corresponding directory listings to be unlisted n= umbers >>> and launch telemarketing calls.=20 > In 8) B) only "open numbering plan" are mentioned but we hope the I-D a= lso cover "closed numbering plan". >>> We intend to cover closed as well. Open plans are specifically cited = because they raise >>> issues for certain potential solutions (i.e., non-terminal NAPTRs). W= e'll change this >>> to read "open as well as closed" > In 8 F) and G) the terms "end-user ENUM" and "private ENUM" are used - = this terms, together with User ENUM and infrastructure ENUM could be defi= ned in this I-D/RFC. >=20 > Clause 3 > The statements in the second paragraph about register all allocated num= ber to avoid identification of unlisted numbers is a little bit unclear -= please explain this better in the I-D/RFC >=20 > Clause 5 > The I-D author could correct the version number of [3] of ITU-T Recomme= ndation E.164 as he also is the editor of E.164. >=20 > Sincerely > Joakim Str=E5lmark > Swedish Administration/NRA > Tel. +46 70 811 40 64=20 >=20 > -----Ursprungligt meddelande----- > Fr=E5n: Richard Shockey [mailto:richard@shockey.us]=20 > Skickat: den 25 mars 2006 21:52 > Till: enum@ietf.org > Kopia: Cullen Jennings; =3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr?=3D; =F6m; = Peterson,Jon > =C4mne: [Enum] ENUM Working Group Last call on Infrastructure ENUMRequi= rements >=20 >=20 >=20 > Title : Infrastructure ENUM Requirements > Author(s) : S. Lind, P. Pfautz > Filename : draft-ietf-enum-infrastructure-enum-reqs-01.txt > Pages : 8 > Date : 2006-3-23 > =09 > This document provides requirements for "infrastructure" or "carrier" > ENUM (E.164 Number Mapping), defined as the use of RFC 3761 > technology to facilitate interconnection of networks for E.164 number > addressed services, in particular but not restricted to VoIP (Voice > over IP.) >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum= -reqs-01.txt >=20 >=20 >=20 > The intent of the last call is to solicit comments before submitting th= e > ID to the IESG as a Proposed Standard. >=20 > This document has been under extensive discussion since early 2005. >=20 > The purpose of a working group Last Call is in the style of "speak now > or forever hold your peace" in case there are fundamental objections > which have not gotten previous or adequate discussion, or minor errors > which need correction. >=20 > Work group last call will extend for 3 weeks or so from Monday Mar 27 > until at least April 17 though we can modify that if new issues come up. >=20 >=20 --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 19 08:18:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWBdO-00068Z-VC; Wed, 19 Apr 2006 08:18:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWBdN-00068U-Kw for enum@ietf.org; Wed, 19 Apr 2006 08:18:13 -0400 Received: from charles.frobbit.se ([85.30.129.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWBdM-00082y-5W for enum@ietf.org; Wed, 19 Apr 2006 08:18:13 -0400 Received: from charles.frobbit.se (localhost [127.0.0.1]) by charles.frobbit.se (8.13.4/8.13.4) with ESMTP id k3JCI9gR007292; Wed, 19 Apr 2006 14:18:09 +0200 (CEST) (envelope-from www@charles.frobbit.se) Received: (from www@localhost) by charles.frobbit.se (8.13.4/8.12.10/Submit) id k3JCI9ps007291; Wed, 19 Apr 2006 14:18:09 +0200 (CEST) (envelope-from www) Date: Wed, 19 Apr 2006 14:18:09 +0200 (CEST) From: "LOTTO NDETHERLANDS via RT" <3761bis@frobbit.se> In-Reply-To: <567a01c66396$ab994270$afacc61f@photonld> References: <567a01c66396$ab994270$afacc61f@photonld> Message-ID: Precedence: bulk X-RT-Loop-Prevention: ticket.frobbit.se RT-Ticket: ticket.frobbit.se #1008 Managed-by: RT 3.4.4 (http://www.bestpractical.com/rt/) RT-Originator: photonld@zwallet.com Cc: enum@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by charles.frobbit.se id k3JCI9gR007292 X-Spam-Score: 0.4 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [Enum] [ticket.frobbit.se #1008] URGENT NOTIFICATION!!! X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Reply-To: 3761bis@frobbit.se List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Wed Apr 19 14:18:09 2006: Request 1008 was acted upon. Transaction: Ticket created by photonld@zwallet.com Queue: 3761bis Subject: URGENT NOTIFICATION!!! Owner: Nobody Requestors: photonld@zwallet.com Status: new Ticket Lotto. NL Patenlaan 23, 2288ee Rijwijk Den Haag, the Netherlands. (Lotto affiliate with Subscriber Agents). From: Joan Van Henk(Lottery Co-ordinator) Website: www.lotto.nl ATTN: WINNER CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners Intern= ational programs held on the 13th Aprail, 2006. Your e-mail address attac= hed to ticket #: 0175655522 with prize #: 31765549 NL drew =EF=BF=BD1,000,000.00 which was first in the first class of the dra= ws. You are to receive =EF=BF=BD1,000,000.00 (One Million Euros). Because= of mix up in cash pay-outs, we ask that you keep your winning informatio= n=20 Confidential until your money (=EF=BF=BD1,000,000.00) has been fully remi= tted to you by our accredited pay-point bank. This measure must be adhere= to, in order to avoid loss of your cash prize - winners of our cash=20 prizes are advised to adhere to these instructions to forestall the abuse= of this program by other participants. It is important to note that this= draws were conducted formally, and winners are selected through=20 an internet ballot system from 50,000 individual and companies e-mail add= resses - the draws are conducted around the world through our internet ba= sed ballot system. The promotion is sponsored and=20 promoted Lotto NL . We congratulate you once again. We hope you will use = part of it in our next draws; the jackpot winning is =EF=BF=BD85million. = Remember, all winnings must be claimed not later than 15days=20 from today. After this date all unclaimed cash prize will be forfeited an= d included in the next sweepstake. Please, in order to avoid unnecessary = delays and complications remember to quote personal and=20 winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL.=20 Thank you for being part of our promotional program. For immediate release of your cash prize to you, please kindly contact ou= r Paying Bank with the information written below.=20 Send them the following information:=20 (i) Your name (ii) Contact telephone and fax numbers (iii) Contact Address (iv)Your winning numbers (v) Quote amount won. (vi) Notification date. Contact person: Mr. Patrick Rowley=09 E-mail: leedcbk@netscape.net Tel: +31 633 701 450 Congratulations once again. Yours in service, Joan Van Henk(Lottery Co-ordinator) Website: www.lotto.nl _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 19 10:01:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWDFU-00050W-Dw; Wed, 19 Apr 2006 10:01:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWDFT-00050N-DS for enum@ietf.org; Wed, 19 Apr 2006 10:01:39 -0400 Received: from charles.frobbit.se ([85.30.129.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWDFR-0004qE-Ut for enum@ietf.org; Wed, 19 Apr 2006 10:01:39 -0400 Received: from charles.frobbit.se (localhost [127.0.0.1]) by charles.frobbit.se (8.13.4/8.13.4) with ESMTP id k3JE1ZHT007595; Wed, 19 Apr 2006 16:01:36 +0200 (CEST) (envelope-from www@charles.frobbit.se) Received: (from www@localhost) by charles.frobbit.se (8.13.4/8.12.10/Submit) id k3JE1Zna007594; Wed, 19 Apr 2006 16:01:35 +0200 (CEST) (envelope-from www) Date: Wed, 19 Apr 2006 16:01:35 +0200 (CEST) From: "Joachim Strohbach/Denic via RT" <3761bis@frobbit.se> In-Reply-To: References: Message-ID: Precedence: bulk X-RT-Loop-Prevention: ticket.frobbit.se RT-Ticket: ticket.frobbit.se #1009 Managed-by: RT 3.4.4 (http://www.bestpractical.com/rt/) RT-Originator: strohbach@denic.de Cc: enum@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by charles.frobbit.se id k3JE1ZHT007595 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Enum] =?utf-8?q?=5Bticket=2Efrobbit=2Ese_=231009=5D_Joachim_Str?= =?utf-8?q?ohbach/DENIC_ist_au=C3=9Fer_Haus=2E?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Reply-To: 3761bis@frobbit.se List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Wed Apr 19 16:01:35 2006: Request 1009 was acted upon. Transaction: Ticket created by strohbach@denic.de Queue: 3761bis Subject: Joachim Strohbach/DENIC ist au=C3=9Fer Haus. Owner: Nobody Requestors: strohbach@denic.de Status: new Ticket Ich werde ab 18.04.2006 nicht im B=C3=BCro sein. Ich kehre zur=C3=BCck a= m 24.04.2006. --- Danke f=C3=BCr Ihre Email-Nachricht. Ich bin bis 24. April 2006 nicht im B=C3=BCro. In dringenden Angelegenhei= ten kontaktieren Sie bitte DENICoperations (Email: ops@denic.de, Tel. 069/27235-272). --- Thank you for your email message. I am not in the office until April 24, 2006. In urgent cases please conta= ct DENICoperations (Email: ops@denic.de, Tel. +49 69 27235 272). --- =3D=3D[strohbach@denic.de]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[http://www.de= nic.de]=3D=3D=3D=3D Joachim Strohbach | DENIC eG Fon: +49 69 27235 123 | Wiesenh=C3=BCttenplatz 26 Fon: +49 69 27235 272 | 60329 Frankfurt/Main Fax: +49 69 27235 234 | DE SIP-URI: sip:123@denic.de | MSN-messenger: strohbach@denic.de =3D=3D[PGP-KeyID: 0x7A8A00FF]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 30AB 0F15 17D3 995F CA50 F0A8 EA30 B915 7A8A 00FF =3D=3D[Leiter Betrieb]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[Head = of Operations]=3D=3D=3D=3D=3D _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 24 14:10:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5Vc-0008Sv-SC; Mon, 24 Apr 2006 14:10:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5Vb-0008NP-02 for enum@ietf.org; Mon, 24 Apr 2006 14:10:03 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FY5Va-0000Uo-E1 for enum@ietf.org; Mon, 24 Apr 2006 14:10:02 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1145902176!7584740!11 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9049 invoked from network); 24 Apr 2006 18:10:01 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-3.tower-121.messagelabs.com with SMTP; 24 Apr 2006 18:10:01 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 44426B370012AA41; Mon, 24 Apr 2006 14:09:59 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C667CA.4CB7FFE9" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 24 Apr 2006 14:09:58 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0CA3FB49@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <4425AD81.1090805@shockey.us> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ENUM Working Group Last call on Infrastructure ENUM Requirements Thread-Index: AcZQThcAyBm0qzvISqyNiSoGiCS+kgXevMRw From: "Pfautz, Penn L, NEO" To: "Richard Shockey" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: Cullen Jennings , =?ISO-8859-1?Q?Patrik_F=E4ltstr?=, =?iso-8859-1?B?9m0=?= , "Peterson, Jon" Subject: [Enum] RE: ENUM Working Group Last call on Infrastructure ENUM Requirements X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C667CA.4CB7FFE9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Attached is a revision of the Infrastructure ENUM Requirements document = to reflect the comments received during last call. (The formal = submission via 'internet-drafts@ietf.org' in progress.) The major substantive change is a more deterministic definition of = "carrier-of-record" at the behest Joakim Stralmark. Penn Pfautz ------_=_NextPart_001_01C667CA.4CB7FFE9 Content-Type: text/plain; name="draft-ietf-enum-infrastructure-enum-req-02.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-enum-infrastructure-enum-req-02.txt Content-Disposition: attachment; filename="draft-ietf-enum-infrastructure-enum-req-02.txt" 77u/DQoNCg0KDQpFTlVNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFMuIExpbmQNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFUJlQgTGFicw0KRXhwaXJlczogT2N0 b2JlciAyNiwgMjAwNiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUC4gUGZh dXR6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEFUJlQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAyNCwgMjAwNg0KDQoNCiAgICAgICAgICAgICAg ICAgICAgSW5mcmFzdHJ1Y3VyZSBFTlVNIFJlcXVpcmVtZW50cw0KICAgICAgICAgICAgICBkcmFm dC1pZXRmLWVudW0taW5mcmFzdHJ1Y3R1cmUtZW51bS1yZXFzLTAyDQoNClN0YXR1cyBvZiB0aGlz IE1lbW8NCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1dGhv ciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIg Y2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQ0KICAgaGF2ZSBiZWVuIG9yIHdpbGwg YmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBhd2Fy ZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1Ag NzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIElu dGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQg aXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28g ZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0K ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11 bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNv bGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBo dHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0 IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQN CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgd2lsbCBleHBpcmUgb24gT2N0b2JlciAyNiwgMjAwNi4NCg0KQ29weXJpZ2h0IE5vdGlj ZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA2KS4NCg0KQWJz dHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyByZXF1aXJlbWVudHMgZm9yICJpbmZy YXN0cnVjdHVyZSIgb3IgImNhcnJpZXIiDQogICBFTlVNIChFLjE2NCBOdW1iZXIgTWFwcGluZyks IGRlZmluZWQgYXMgdGhlIHVzZSBvZiBSRkMgMzc2MQ0KICAgdGVjaG5vbG9neSB0byBmYWNpbGl0 YXRlIGludGVyY29ubmVjdGlvbiBvZiBuZXR3b3JrcyBmb3IgRS4xNjQgbnVtYmVyDQogICBhZGRy ZXNzZWQgc2VydmljZXMsIGluIHBhcnRpY3VsYXIgYnV0IG5vdCByZXN0cmljdGVkIHRvIFZvSVAg KFZvaWNlDQogICBvdmVyIElQLikNCg0KQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50 DQoNCg0KDQpMaW5kICYgUGZhdXR6ICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjYsIDIwMDYg ICAgICAgICAgICAgICAgW1BhZ2UgMV0NCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgIEluZnJhc3Ry dWN0dXJlIEVOVU0gUmVxdWlyZW1lbnRzICAgICAgICAgIEFwcmlsIDIwMDYNCg0KDQogICBSRkMy MTE5IFsxXSBwcm92aWRlcyB0aGUgaW50ZXJwcmV0YXRpb25zIGZvciB0aGUga2V5IHdvcmRzICJN VVNUIiwNCiAgICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCAi U0hPVUxEIiwgIlNIT1VMRCBOT1QiLA0KICAgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BU SU9OQUwiIGZvdW5kIGluIHRoaXMgZG9jdW1lbnQuDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0K ICAgMS4gIEluZnJhc3RydWN0dXJlIEVOVU0gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAzDQogICAgIDEuMS4gIERlZmluaXRpb24gIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMNCiAgICAgMS4yLiAgQmFja2dyb3VuZCAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMw0KICAgMi4g IFJlcXVpcmVtZW50cyBmb3IgSW5mcmFzdHJ1Y3R1cmUgRU5VTSAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA0DQogICAzLiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUNCiAgIDQuICBJQU5BIENvbnNpZGVyYXRpb25zIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQ0KICAgNS4gIE5vcm1h dGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA1DQogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDcNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJp Z2h0IFN0YXRlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gOA0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkxpbmQg JiBQZmF1dHogICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNiwgMjAwNiAgICAgICAgICAgICAg ICBbUGFnZSAyXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgSW5mcmFzdHJ1Y3R1cmUgRU5VTSBS ZXF1aXJlbWVudHMgICAgICAgICAgQXByaWwgMjAwNg0KDQoNCjEuICBJbmZyYXN0cnVjdHVyZSBF TlVNDQoNCjEuMS4gIERlZmluaXRpb24NCg0KICAgSW5mcmFzdHJ1Y3R1cmUgRU5VTSBpcyBkZWZp bmVkIGFzIHRoZSB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgaW4NCiAgIFJGQzM3NjEgWzJdIGJ5IHRo ZSBjYXJyaWVyLW9mLXJlY29yZCBmb3IgYSBzcGVjaWZpYyBFLjE2NCBudW1iZXIgWzNdDQogICB0 byBtYXAgYSB0ZWxlcGhvbmUgbnVtYmVyIGludG8gYSBVUkkgWzRdIHRoYXQgaWRlbnRpZmllcyBh IHNwZWNpZmljDQogICBwb2ludCBvZiBpbnRlcmNvbm5lY3Rpb24gdG8gdGhhdCBzZXJ2aWNlIHBy b3ZpZGVyJ3MgbmV0d29yayB0aGF0DQogICBjb3VsZCBlbmFibGUgdGhlIG9yaWdpbmF0aW5nIHBh cnR5IHRvIGVzdGFibGlzaCBjb21tdW5pY2F0aW9uIHdpdGgNCiAgIHRoZSBhc3NvY2lhdGVkIHRl cm1pbmF0aW5nIHBhcnR5LiAgSXQgaXMgc2VwYXJhdGUgZnJvbSBhbnkgVVJJcyB0aGF0DQogICB0 aGUgZW5kLXVzZXIsIHdobyByZWdpc3RlcnMgdGhlaXIgRS4xNjQgbnVtYmVyLCBtYXkgd2lzaCB0 byBhc3NvY2lhdGUNCiAgIHdpdGggdGhhdCBFLjE2NCBudW1iZXIuDQoNCiAgIEluZnJhc3RydWN0 dXJlIEVOVU0gaXMgZGlzdGluZ3Vpc2hlZCBmcm9tIHVzZXIgRU5VTSwgZGVmaW5lZCBpbg0KICAg UkZDMzc2MSBbMl0sIGluIHdoaWNoIHRoZSBlbnRpdHkgb3IgcGVyc29uIGhhdmluZyB0aGUgcmln aHQtdG8tdXNlIGENCiAgIG51bWJlciBoYXMgdGhlIHNvbGUgZGlzY3JldGlvbiBhYm91dCB0aGUg Y29udGVudCBvZiB0aGUgYXNzb2NpYXRlZA0KICAgZG9tYWluIGFuZCB0aHVzIHRoZSB6b25lIGNv bnRlbnQuICBGcm9tIGEgZG9tYWluIHJlZ2lzdHJhdGlvbg0KICAgcGVyc3BlY3RpdmUsIHRoZSBl bmQgdXNlciBudW1iZXIgYXNzaWduZWUgaXMgdGh1cyB0aGUgcmVnaXN0cmFudC4NCiAgIFdpdGhp biB0aGUgaW5mcmFzdHJ1Y3R1cmUgRU5VTSBuYW1lc3BhY2UsIHdlIHVzZSB0aGUgdGVybSAiY2Fy cmllci0NCiAgIG9mLXJlY29yZCIgZm9yIHRoZSBlbnRpdHkgaGF2aW5nIGRpc2NyZXRpb24gb3Zl ciB0aGUgZG9tYWluIGFuZCB6b25lDQogICBjb250ZW50IGFuZCBhY3RpbmcgYXMgdGhlIHJlZ2lz dHJhbnQuICBUaGUgImNhcnJpZXItb2YtcmVjb3JkIiBpczoNCg0KICAgbyBUaGUgU2VydmljZSBQ cm92aWRlciB0byB3aGljaCB0aGUgRS4xNjQgbnVtYmVyIHdhcyBhbGxvY2F0ZWQgZm9yDQogICBl bmQgdXNlciBhc3NpZ25tZW50LCB3aGV0aGVyIGJ5IHRoZSBOYXRpb25hbCBSZWd1bGF0b3J5IEF1 dGhvcml0eQ0KICAgKE5SQSkgb3IgdGhlIEludGVybmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb24g VW5pb24gKElUVSksIGZvcg0KICAgaW5zdGFuY2UgYSBjb2RlIHVuZGVyICJJbnRlcm5hdGlvbmFs IE5ldHdvcmtzIiAoKzg4Mikgb3IgIlVuaXZlcnNhbA0KICAgUGVyc29uYWwgVGVsZWNvbW11bmlj YXRpb25zIChVUFQpIiAoKzg3OCkgb3IsDQoNCiAgIG8gaWYgdGhlIG51bWJlciBpcyBwb3J0ZWQs IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIHRvIHdoaWNoIHRoZSBudW1iZXINCiAgIHdhcyBwb3J0ZWQs IG9yDQoNCiAgIG8gd2hlcmUgbnVtYmVycyBhcmUgYXNzaWduZWQgZGlyZWN0bHkgdG8gZW5kIHVz ZXJzLCB0aGUgc2VydmljZQ0KICAgcHJvdmlkZXIgdGhhdCB0aGUgZW5kIHVzZXIgbnVtYmVyIGFz c2lnbmVlIGhhcyBjaG9zZW4gdG8gcHJvdmlkZSBhDQogICBQdWJsaWMgU3dpdGNoZWQgVGVsZXBo b25lIE5ldHdvcmsvUHVibGljIExhbmQgTW9iaWxlIE5ldHdvcmsgKFBTVE4vDQogICBQTE1OKSBw b2ludC1vZi1pbnRlcmNvbm5lY3QgZm9yIHRoZSBudW1iZXINCg0KICAgSXQgaXMgdW5kZXJzdG9v ZCB0aGF0IHRoZSBkZWZpbml0aW9uIG9mIGNhcnJpZXItb2YtcmVjb3JkIHdpdGhpbiBhDQogICBn aXZlbiBqdXJpc2RpY3Rpb24gaXMgc3ViamVjdCB0byBtb2RpZmljYXRpb24gYnkgbmF0aW9uYWwN CiAgIGF1dGhvcml0aWVzLg0KDQoxLjIuICBCYWNrZ3JvdW5kDQoNCiAgIFZvaWNlIHNlcnZpY2Ug cHJvdmlkZXJzIHVzZSBFLjE2NCBudW1iZXJzIGN1cnJlbnRseSBhcyB0aGVpciBtYWluDQogICBu YW1pbmcgYW5kIHJvdXRpbmcgdmVoaWNsZS4gIEluZnJhc3RydWN0dXJlIEVOVU0gaW4gZTE2NC5h cnBhIG9yDQogICBhbm90aGVyIHB1YmxpY2x5IGF2YWlsYWJsZSB0cmVlIGFsbG93cyBzZXJ2aWNl IHByb3ZpZGVycyB0byBsaW5rDQogICBJbnRlcm5ldCBiYXNlZCByZXNvdXJjZXMgc3VjaCBhcyBV UklzIHRvIEUuMTY0IG51bWJlcnMuICBUaGlzIGFsbG93cw0KICAgc2VydmljZSBwcm92aWRlcnMg aW4gYWRkaXRpb24gdG8gaW50ZXJjb25uZWN0aW5nIHZpYSB0aGUgUFNUTi9QTE1ODQogICAob3Ig ZXhjbHVzaXZlbHkpIHRvIHBlZXIgdmlhIElQLWJhc2VkIHByb3RvY29scy4gIFNlcnZpY2UgcHJv dmlkZXJzDQoNCg0KDQpMaW5kICYgUGZhdXR6ICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjYs IDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgM10NCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgIElu ZnJhc3RydWN0dXJlIEVOVU0gUmVxdWlyZW1lbnRzICAgICAgICAgIEFwcmlsIDIwMDYNCg0KDQog ICBtYXkgYW5ub3VuY2UgYWxsIEUuMTY0IG51bWJlcnMgb3IgbnVtYmVyIHJhbmdlcyB0aGV5IGhv c3QsIHJlZ2FyZGxlc3MNCiAgIG9mIHdoZXRoZXIgdGhlIGZpbmFsIGVuZC11c2VyIGRldmljZSBp cyBvbiB0aGUgSW50ZXJuZXQsIG9uIElQLWJhc2VkDQogICBvcGVuIG9yIGNsb3NlZCBOZXh0IEdl bmVyYXRpb24gTmV0d29ya3MgKE5HTnMpIG9yIG9uIHRoZSBQU1ROIG9yDQogICBQTE1OLCBwcm92 aWRlZCBhbiBhY2Nlc3MgKGUuZy4sIFNlc3Npb24gQm9yZGVyIENvbnRyb2xsZXIgKFNCQykgb3IN CiAgIGdhdGV3YXkpIHRvIHRoZSBkZXN0aW5hdGlvbiBzZXJ2aWNlIHByb3ZpZGVyJ3MgbmV0d29y ayBpcyBhdmFpbGFibGUNCiAgIG9uIHRoZSBJbnRlcm5ldC4gIFRoZXJlIGlzIGFsc28gbm8gZ3Vh cmFudGVlIHRoYXQgdGhlIG9yaWdpbmF0aW5nDQogICBzZXJ2aWNlIHByb3ZpZGVyIHF1ZXJ5aW5n IGluZnJhc3RydWN0dXJlIEVOVU0gaXMgYWJsZSB0byBhY2Nlc3MgdGhlDQogICBpbmdyZXNzIG5l dHdvcmsgZWxlbWVudCBvZiB0aGUgZGVzdGluYXRpb24gcHJvdmlkZXIncyBuZXR3b3JrLg0KICAg QWRkaXRpb25hbCBwZWVyaW5nIGFuZCBhY2NvdW50aW5nIGFncmVlbWVudHMgcmVxdWlyaW5nIGF1 dGhlbnRpY2F0aW9uDQogICBtYXkgYmUgbmVjZXNzYXJ5LiAgVGhlIGFjY2VzcyBwcm92aWRlZCBt YXkgYWxzbyBiZSB0byBhIHNoYXJlZA0KICAgbmV0d29yayBvZiBhIGdyb3VwIG9mIHByb3ZpZGVy cywgcmVzb2x2aW5nIHRoZSBmaW5hbCBkZXN0aW5hdGlvbg0KICAgbmV0d29yayB3aXRoaW4gdGhl IHNoYXJlZCBuZXR3b3JrLg0KDQoNCjIuICBSZXF1aXJlbWVudHMgZm9yIEluZnJhc3RydWN0dXJl IEVOVU0NCg0KICAgMS4gIEluZnJhc3RydWN0dXJlIEVOVU0gU0hBTEwgcHJvdmlkZSBhIG1lYW5z IGZvciBhIHByb3ZpZGVyIHRvDQogICAgICAgcG9wdWxhdGUgRE5TIHJlc291cmNlIHJlY29yZHMg KFJScykgZm9yIHRoZSBFLjE2NCBudW1iZXJpbmcNCiAgICAgICByZXNvdXJjZXMgZm9yIHdoaWNo IGl0IGlzIHRoZSBjYXJyaWVyLW9mLXJlY29yZCBpbiBhIHNpbmdsZQ0KICAgICAgIGNvbW1vbiBw dWJsaWNseSBhY2Nlc3NpYmxlIG5hbWVzcGFjZS4gIFRoZSBzaW5nbGUgY29tbW9uDQogICAgICAg bmFtZXNwYWNlIHVsaW10YXRlbHkgZGVzaWduYXRlZCBtYXkgb3IgbWF5IG5vdCBiZSB0aGUgc2Ft ZSBhcw0KICAgICAgIHRoYXQgZGVzaWduYXRlZCBmb3IgdXNlciBFTlVNIChlMTY0LmFycGEuKQ0K ICAgMi4gIFF1ZXJpZXMgb2YgaW5mcmFzdHJ1Y3R1cmUgRU5VTSBmdWxseSBxdWFsaWZpZWQgZG9t YWluIG5hbWVzIE1VU1QNCiAgICAgICByZXR1cm4gYSByZXN1bHQsIGV2ZW4gaWYgdGhlIHJlc3Vs dCBpcyBOWERPTUFJTi4gIFF1ZXJpZXMgbXVzdA0KICAgICAgIG5vdCBiZSByZWplY3RlZCwgZS5n LiwgYmFzZWQgb24gYWNjZXNzIGNvbnRyb2wgbGlzdHMuDQogICAzLiAgSW5mcmFzdHJ1Y3R1cmUg RU5VTSBTSEFMTCBzdXBwb3J0IFJScyBwcm92aWRpbmcgYSBVUkkgdGhhdCBjYW4NCiAgICAgICBp ZGVudGlmeSBhIHBvaW50IG9mIGludGVyY29ubmVjdGlvbiBmb3IgZGVsaXZlcnkgdG8gdGhlIGNh cnJpZXItDQogICAgICAgb2YtcmVjb3JkIG9mIGNvbW11bmljYXRpb25zIGFkZHJlc3NlZCB0byB0 aGUgRS4xNjQgbnVtYmVyLg0KICAgNC4gIEluZnJhc3RydWN0dXJlIEVOVU0gU0hBTEwgc3VwcG9y dCBhbiBJUklTIFs1XSBjYXBhYmlsaXR5IHRoYXQNCiAgICAgICBhbGxvd3MgcXVhbGlmaWVkIHBh cnRpZXMgdG8gb2J0YWluIGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUNCiAgICAgICBFLjE2NCBu dW1iZXJpbmcgcmVzb3VyY2VzIGFuZCB0aGUgY29ycmVzcG9uZGluZyBjYXJyaWVyLW9mLQ0KICAg ICAgIHJlY29yZC4gIERldGVybWluYXRpb24gb2Ygd2hhdCBpbmZvcm1hdGlvbiwgaWYgYW55LCBz aGFsbCBiZQ0KICAgICAgIGF2YWlsYWJsZSB0byB3aGljaCBwYXJ0aWVzIGlzIGEgbmF0aW9uYWwg bWF0dGVyLg0KICAgNS4gIEltcGxlbWVudGF0aW9uIG9mIEluZnJhc3RydWN0dXJlIEVOVU0gTVVT VCBOT1QgcmVzdHJpY3QgdGhlDQogICAgICAgYWJpbGl0eSBvZiBhbiBlbmQtdXNlciwgaW4gYSBj b21wZXRpdGl2ZSBlbnZpcm9ubWVudCwgdG8gY2hvb3NlIGENCiAgICAgICBSZWdpc3RyYXIgYW5k L29yIFRpZXIgMiBuYW1lIHNlcnZlciBwcm92aWRlciBmb3IgZW5kLXVzZXIgRU5VTQ0KICAgICAg IHJlZ2lzdHJhdGlvbnMuDQogICA2LiAgSW5mcmFzdHJ1Y3R1cmUgRU5VTSBTSEFMTCBiZSBpbXBs ZW1lbnRlZCB1bmRlciBhIHRvcCBsZXZlbCBkb21haW4NCiAgICAgICB0aGF0IGNhbiBzdXBwb3J0 IHJlbGlhYmlsaXR5IGFuZCBwZXJmb3JtYW5jZSBzdWl0YWJsZSBmb3IgUFNUTi8NCiAgICAgICBQ TE1OIGFwcGxpY2F0aW9ucy4NCiAgIDcuICBJbmZyYXN0cnVjdHVyZSBFTlVNIE1VU1QgbWVldCBh bGwgcmVhc29uYWJsZSBwcml2YWN5IGNvbmNlcm5zDQogICAgICAgYWJvdXQgdmlzaWJpbGl0eSBv ZiBpbmZvcm1hdGlvbiBhbiBlbmQgdXNlciBoYXMgbm8gY29udHJvbCBvdmVyLg0KICAgICAgIEl0 IHNob3VsZCwgZm9yIGV4YW1wbGUsIHN1cHBvcnQgbWVjaGFuaXNtcyB0byBwcmV2ZW50IGRpc2Nv dmVyeQ0KICAgICAgIG9mIHVubGlzdGVkIG51bWJlcnMgYnkgY29tcGFyaXNpb24gb2YgRU5VTSBy ZWdpc3RyYXRpb25zIGFnYWluc3QNCiAgICAgICBkaXJlY3RvcnkgbGlzdGluZ3MsIG9yIGluYWR2 ZXJ0ZW50IGRpc2Nsb3N1cmUgb2YgdXNlciBpZGVudGl0eS4NCiAgIDguICBQcm9wb3NlZCBpbXBs ZW1lbnRhdGlvbnMgb2YgSW5mcmFzdHJ1Y3R1cmUgRU5VTSBTSE9VTEQ6DQoNCg0KDQoNCg0KTGlu ZCAmIFBmYXV0eiAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI2LCAyMDA2ICAgICAgICAgICAg ICAgIFtQYWdlIDRdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICBJbmZyYXN0cnVjdHVyZSBFTlVN IFJlcXVpcmVtZW50cyAgICAgICAgICBBcHJpbCAyMDA2DQoNCg0KICAgICAgIEEuICBNaW5pbWl6 ZSBjaGFuZ2VzIHJlcXVpcmVkIHRvIGV4aXN0aW5nIHJlcXVpcmVtZW50cyB0aGF0IGFyZQ0KICAg ICAgICAgICBwYXJ0IG9mIFJGQyAzNzYxDQogICAgICAgQi4gIFdvcmsgd2l0aCBvcGVuIGFzIHdl bGwgYXMgY2xvc2VkIG51bWJlcmluZyBwbGFucw0KICAgICAgIEMuICBSZXN0cmljdCB0aGUgbmVl ZCBmb3IgYW55IGFkZGl0aW9uYWwgcmVzb2x2ZXIgZnVuY3Rpb25hbGl0eQ0KICAgICAgICAgICB0 byBzZXJ2aWNlIHByb3ZpZGVyIHJlc29sdmVycy4NCiAgICAgICBELiAgTWluaW1pemUgdGhlIG51 bWJlciBvZiBsb29rdXBzIHJlcXVpcmVkIHRvIG9idGFpbiBhcyBtYW55DQogICAgICAgICAgIE5B UFRSIChOYW1pbmcgQXV0aG9yaXR5IFBvaW50ZXIpIHJlY29yZHMgKGVuZC11c2VyIGFuZA0KICAg ICAgICAgICBpbmZyYXN0cnVjdHVyZSkgYXMgcG9zc2libGUuDQogICAgICAgRS4gIE1pbmltaXpl IHRoZSBjbGllbnQga25vd2xlZGdlIG9mIHRoZSBudW1iZXJpbmcgcGxhbiByZXF1aXJlZC4NCiAg ICAgICBGLiAgTWF4aW1pemUgc3luZXJnaWVzIHdpdGggZW5kLXVzZXIgRU5VTQ0KICAgICAgIEcu ICBTdXBwb3J0IGludGVyd29ya2luZyB3aXRoIHByaXZhdGUgRU5VTSB0cmVlcy4oSW4gdGhpcyBj b250ZXh0DQogICAgICAgICAgIGEgcHJpdmF0ZSBFTlVNIHRyZWUgaXMgb25lIHRoYXQgaXMgbm90 IHVuZGVyIGUxNjQuYXJwYSBvcg0KICAgICAgICAgICB3aGF0ZXZlciBuYW1lc3BhY2UgaXMgY2hv c2VuIGZvciBpbmZyYXN0cnVjdHVyZSBFTlVNIGJ1dCB1c2VzDQogICAgICAgICAgIGluc3RlYWQg YSBwcml2YXRlbHkgaGVsZCBkb21haW4uKQ0KDQoNCjMuICBTZWN1cml0eSBDb25zaWRlcmF0aW9u cw0KDQogICBFeGlzdGluZyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgRU5VTSBkZXRhaWxl ZCBpbiBbMl0gc3RpbGwNCiAgIGFwcGx5LiAgTm90ZSB0aGF0IHNvbWUgcmVnaXN0cmF0aW9uIHZh bGlkYXRpb24gaXNzdWVzIGNvbmNlcm5pbmcgZW5kDQogICB1c2VyIEVOVU0gbWF5IG5vdCBhcHBs eSB0byBpbmZyYXN0cnVjdHVyZSBFTlVNLiAgV2hlcmUgdGhlIFRpZXIgMQ0KICAgcmVnaXN0cnkg aXMgYWJsZSB0byBpZGVudGlmeSB0aGUgcHJvdmlkZXIgc2VydmluZyBhIG51bWJlciBlLmcuLA0K ICAgYmFzZWQgb24gaW5kdXN0cnkgZGF0YSBmb3IgbnVtYmVyIGJsb2NrIGFzc2lnbm1lbnRzIGFu ZCBudW1iZXINCiAgIHBvcnRhYmlsaXR5LCByZWdpc3RyYXRpb24gbWlnaHQgYmUgbW9yZSBlYXNp bHkgYXV0b21hdGVkIGFuZCBhDQogICBzZXBhcmF0ZSByZWdpc3RyYXIgbm90IHJlcXVpcmVkLg0K DQogICBTb21lIHBhcnRpZXMgaGF2ZSBleHByZXNzZWQgY29uY2VybiB0aGF0IGFuIGluZnJhc3Ry dWN0dXJlIEVOVU0gY291bGQNCiAgIGNvbXByb21pc2UgZW5kIHVzZXIgcHJpdmFjeSBieSBtYWtp bmcgaXQgcG9zc2libGUgZm9yIG90aGVycyB0bw0KICAgaWRlbnRpZnkgdW5saXN0ZWQgb3IgdW5w dWJsaXNoZWQgbnVtYmVycyBiYXNlZCBvbiB0aGVpciByZWdpc3RyYXRpb24NCiAgIGluIEVOVU0u ICBUaGlzIGNhbiBiZSBhdm9pZGVkIGlmIHByb3ZpZGVycyByZWdpc3RlciBhbGwgb2YgdGhlIHRo ZWlyDQogICBhbGxvY2F0ZWQgKGFzIG9wcG9zZWQgdG8gYXNzaWduZWQpIG51bWJlcnMuICBVbmFz c2lnbmVkIG51bWJlcnMNCiAgIHNob3VsZCBiZSBwcm92aXNpb25lZCB0byByb3V0ZSB0byB0aGUg cHJvdmlkZXIncyBuZXR3b3JrIGluIHRoZSBzYW1lDQogICBmYXNoaW9uIGFzIGFzc2lnbmVkIG51 bWJlcnMgYW5kIG9ubHkgdGhlbiBwcm92aWRlIGFuIGluZGljYXRpb24gdGhhdA0KICAgdGhleSBh cmUgdW5hc3NpZ25lZC4gIEluIHRoYXQgd2F5LCBwcm92aWRlciByZWdpc3RyYXRpb24gb2YgYSBu dW1iZXINCiAgIGluIEVOVU0gcHJvdmlkZXMgbm8gbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBzdGF0 dXMgb2YgYSBudW1iZXIgdGhhbg0KICAgY291bGQgYmUgb2J0YWluZWQgYnkgZGlhbGluZyBpdC4N Cg0KDQo0LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBJQU5BIGNvbnNpZGVyYXRpb25zIHdp bGwgZGVwZW5kIG9uIHRoZSBhcmNoaXRlY3R1cmUgdWx0aW1hdGVseSBjaG9zZW4NCiAgIHRvIG1l ZXQgdGhlIHJlcXVpcmVtZW50cy4NCg0KNS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFsx XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJl cXVpcmVtZW50DQogICAgICAgIExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcu DQoNCg0KDQoNCkxpbmQgJiBQZmF1dHogICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNiwgMjAw NiAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgSW5mcmFz dHJ1Y3R1cmUgRU5VTSBSZXF1aXJlbWVudHMgICAgICAgICAgQXByaWwgMjAwNg0KDQoNCiAgIFsy XSAgRmFsdHN0cm9tLCBQLiBhbmQgTS4gTWVhbGxpbmcsICJUaGUgRS4xNjQgdG8gVW5pZm9ybSBS ZXNvdXJjZQ0KICAgICAgICBJZGVudGlmaWVycyAoVVJJKSBEeW5hbWljIERlbGVnYXRpb24gRGlz Y292ZXJ5IFN5c3RlbSAoREREUykNCiAgICAgICAgQXBwbGljYXRpb24gKEVOVU0pIiwgUkZDIDM3 NjEsIEFwcmlsIDIwMDQuDQoNCiAgIFszXSAgSW50ZXJuYXRpb25hbCBUZWxlY29tbXVuaWNhdGlv biBVbmlvbi1UZWxlY29tbXVuaWNhdGlvbg0KICAgICAgICBTdGFuZGFyZGl6YXRpb24gU2VjdG9y LCAiVGhlIEludGVybmF0aW9uYWwgUHVibGljDQogICAgICAgIFRlbGVjb21tdW5pY2F0aW9uIE51 bWJlcmluZyBQbGFuIiwgUmVjb21tZW5kYXRpb24gRS4xNjQiLA0KICAgICAgICBGZWJydWFyeSAy MDA1Lg0KDQogICBbNF0gIEJlcm5lcnMtTGVlLCBULiwgRmllbGRpbmcsIFIuLCBhbmQgTC4gTWFz aW50ZXIsICJVbmlmb3JtDQogICAgICAgIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSk6IEdlbmVy aWMgU3ludGF4IiwgU1REIDY2LCBSRkMgMzk4NiwNCiAgICAgICAgSmFudWFyeSAyMDA1Lg0KDQog ICBbNV0gIE5ld3RvbiwgQS4gYW5kIE0uIFNhbnosICJJUklTOiBUaGUgSW50ZXJuZXQgUmVnaXN0 cnkgSW5mb3JtYXRpb24NCiAgICAgICAgU2VydmljZSAoSVJJUykgQ29yZSBQcm90b2NvbCIsIFJG QyAzOTgxLCBKYW51YXJ5IDIwMDUuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpMaW5kICYgUGZhdXR6ICAgICAg ICAgICBFeHBpcmVzIE9jdG9iZXIgMjYsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCg0K DQpJbnRlcm5ldC1EcmFmdCAgICAgIEluZnJhc3RydWN0dXJlIEVOVU0gUmVxdWlyZW1lbnRzICAg ICAgICAgIEFwcmlsIDIwMDYNCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgU3RldmVuIExp bmQNCiAgIEFUJlQgTGFicw0KICAgMTgwIFBhcmsgQXZlDQogICBGbG9yaGFtIFBhcmssIE5KICAw NzkzMi0wOTcxDQogICBVU0ENCg0KICAgRW1haWw6IHNsaW5kQGF0dC5jb20NCg0KDQogICBQZW5u IFBmYXV0eg0KICAgQVQmVA0KICAgMjAwIFMuIExhdXJlbCBBdmUNCiAgIE1pZGRsZXRvd24sIE5K ICAwNzc0OA0KICAgVVNBDQoNCiAgIEVtYWlsOiBwcGZhdXR6QGF0dC5jb20NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkxp bmQgJiBQZmF1dHogICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNiwgMjAwNiAgICAgICAgICAg ICAgICBbUGFnZSA3XQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgSW5mcmFzdHJ1Y3R1cmUgRU5V TSBSZXF1aXJlbWVudHMgICAgICAgICAgQXByaWwgMjAwNg0KDQoNCkludGVsbGVjdHVhbCBQcm9w ZXJ0eSBTdGF0ZW1lbnQNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5n IHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBS aWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVydGFp biB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJl ZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNl IHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBu b3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVwZW5kZW50 IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0KICAgb24g dGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNh biBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBvZiBJUFIg ZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQogICBhc3N1 cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9m IGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1p c3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxl bWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5l ZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5 IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9y IHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMgdGhh dCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQN CiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhl IElFVEYgYXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0KDQoNCkRpc2NsYWltZXIgb2YgVmFsaWRp dHkNCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJl aW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVU T1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JF RCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVA0KICAg RU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBP UiBJTVBMSUVELA0KICAgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkg VEhBVCBUSEUgVVNFIE9GIFRIRQ0KICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJ TkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB QklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCkNvcHlyaWdo dCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAw NikuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNCiAgIHRvIHRoZSByaWdodHMsIGxpY2Vuc2Vz IGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kDQogICBleGNlcHQgYXMg c2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0K DQoNCkFja25vd2xlZGdtZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0 aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUNCiAgIEludGVybmV0IFNvY2lldHkuDQoN Cg0KDQoNCkxpbmQgJiBQZmF1dHogICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNiwgMjAwNiAg ICAgICAgICAgICAgICBbUGFnZSA4XQ0KDQoNCg0KDQo= ------_=_NextPart_001_01C667CA.4CB7FFE9 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01C667CA.4CB7FFE9-- From enum-bounces@ietf.org Mon Apr 24 14:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5nM-0006EQ-K7; Mon, 24 Apr 2006 14:28:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5nL-0006EL-6S for enum@ietf.org; Mon, 24 Apr 2006 14:28:23 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY5nJ-0001Yf-PK for enum@ietf.org; Mon, 24 Apr 2006 14:28:23 -0400 Received: from [10.31.13.202] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k3OISbC9025369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Apr 2006 11:28:39 -0700 Message-ID: <444D18B3.2010007@shockey.us> Date: Mon, 24 Apr 2006 14:28:03 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Pfautz, Penn L, NEO" Subject: Re: [Enum] RE: ENUM Working Group Last call on Infrastructure ENUM Requirements References: <34DA635B184A644DA4588E260EC0A25A0CA3FB49@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0CA3FB49@ACCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: enum@ietf.org, Cullen Jennings , paf@cisco.com, "Peterson, Jon" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Pfautz, Penn L, NEO wrote: > Attached is a revision of the Infrastructure ENUM Requirements document to reflect the comments received during last call. (The formal submission via 'internet-drafts@ietf.org' in progress.) > The major substantive change is a more deterministic definition of "carrier-of-record" at the behest Joakim Stralmark. > > Penn Pfautz > As soon as it crosses the ID Editors list we'll begin the publication request. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 24 14:46:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY64n-00045m-Cs; Mon, 24 Apr 2006 14:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY64m-00045h-8m for enum@ietf.org; Mon, 24 Apr 2006 14:46:24 -0400 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY64l-0003K8-2K for enum@ietf.org; Mon, 24 Apr 2006 14:46:24 -0400 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id k3OIoM8j015101; Mon, 24 Apr 2006 14:50:22 -0400 Received: from dul1trutkow-l1.verisign.com ([10.26.0.97]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 14:46:17 -0400 Message-Id: <7.0.1.0.2.20060424192320.02af53d8@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 24 Apr 2006 19:46:10 +0100 To: From: Tony Rutkowski Subject: Re: [Enum] RE: ENUM Working Group Last call on Infrastructure ENUM Requirements In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0CA3FB49@ACCLUST02EVS1.ugd .att.com> References: <4425AD81.1090805@shockey.us> <34DA635B184A644DA4588E260EC0A25A0CA3FB49@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 24 Apr 2006 18:46:18.0559 (UTC) FILETIME=[5F8CC4F0:01C667CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Penn Interesting document. Are you filing a petition for rulemaking for change to the 47 CFR Part 52 to implement it? --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 24 15:13:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY6UU-0005ez-N3; Mon, 24 Apr 2006 15:12:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY6UT-0005cm-2V for enum@ietf.org; Mon, 24 Apr 2006 15:12:57 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FY6UR-0004IC-MO for enum@ietf.org; Mon, 24 Apr 2006 15:12:57 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] RE: ENUM Working Group Last call on InfrastructureENUM Requirements X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 24 Apr 2006 21:14:01 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C49B0@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE: ENUM Working Group Last call on InfrastructureENUM Requirements Thread-Index: AcZn0AUQJ6MRyT0gTW6A0yoyM0cAQgAAznj6 From: "Stastny Richard" To: "Tony Rutkowski" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Tony, =20 if you post such cryptic numbers and letters (47 CFR Part 52) on this = list, coild you please be more specific =20 You should also consider that the IETF is a global standards body and that there are some 200+ other countries out there =20 Richard ________________________________ Von: Tony Rutkowski [mailto:trutkowski@verisign.com] Gesendet: Mo 24.04.2006 20:46 An: ppfautz@att.com Cc: enum@ietf.org Betreff: Re: [Enum] RE: ENUM Working Group Last call on = InfrastructureENUM Requirements Hi Penn Interesting document. Are you filing a petition for rulemaking for change to the 47 CFR Part 52 to implement it? --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 24 15:50:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY74P-0006Ae-D9; Mon, 24 Apr 2006 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY74M-0006A0-JV; Mon, 24 Apr 2006 15:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY74M-0006Nv-87; Mon, 24 Apr 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3OJo1vP007908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FY74L-0002Zu-PN; Mon, 24 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 24 Apr 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by pine.neustar.com id k3OJo1vP007908 A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Telephone Number Mapping Working Group o= f the IETF. Title : The E.164 to Uniform Resource Identifiers=20 (URI) Dynamic Delegation Discovery System=20 (DDDS) Application for Infrastructure ENUM=20 Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-infrastructure-00.txt Pages : 6 Date : 2006-4-24 =09 This document defines a parallel namespace =93ie164.arpa=94 to=20 =93e164.arpa=94 as defined in RFC3761 to be used for Infrastructure ENUM=20 purposes.=20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of th= e message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-infrastructure-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-infrastructure-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-24140359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-infrastructure-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-infrastructure-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-24140359.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Mon Apr 24 16:25:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY7cI-00076Q-9q; Mon, 24 Apr 2006 16:25:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY7cH-000766-5z for enum@ietf.org; Mon, 24 Apr 2006 16:25:05 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY7cD-0008Vs-DV for enum@ietf.org; Mon, 24 Apr 2006 16:25:05 -0400 Received: from ([10.52.116.10]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.18866685; Mon, 24 Apr 2006 16:24:26 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Apr 2006 16:24:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: ENUM Working Group Last call on InfrastructureENUMRequirements Date: Mon, 24 Apr 2006 16:24:25 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305248017@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE: ENUM Working Group Last call on InfrastructureENUMRequirements Thread-Index: AcZn0AUQJ6MRyT0gTW6A0yoyM0cAQgAAznj6AAJl1xA= From: "Livingood, Jason" To: "Stastny Richard" , "Tony Rutkowski" , X-OriginalArrivalTime: 24 Apr 2006 20:24:25.0829 (UTC) FILETIME=[14A2E150:01C667DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I had no idea what that was either. ;-) Google found it, like nearly all else: Code of Federal Regulations, Title 47 Telecommunication=20 http://www.washingtonwatchdog.org/documents/cfr/title47/part52.html=20 So, what does this have to do with changes to this FCC regulatory document?? Jason > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Monday, April 24, 2006 3:14 PM > To: Tony Rutkowski; ppfautz@att.com > Cc: enum@ietf.org > Subject: Re: [Enum] RE: ENUM Working Group Last call on=20 > InfrastructureENUMRequirements >=20 > Tony, > =20 > if you post such cryptic numbers and letters (47 CFR Part 52)=20 > on this list, coild you please be more specific > =20 > You should also consider that the IETF is a global standards=20 > body and that there are some 200+ other countries out there > =20 > Richard >=20 > ________________________________ >=20 > Von: Tony Rutkowski [mailto:trutkowski@verisign.com] > Gesendet: Mo 24.04.2006 20:46 > An: ppfautz@att.com > Cc: enum@ietf.org > Betreff: Re: [Enum] RE: ENUM Working Group Last call on=20 > InfrastructureENUM Requirements >=20 >=20 >=20 > Hi Penn >=20 > Interesting document. Are you filing a petition for=20 > rulemaking for change to the 47 CFR Part 52 to implement it? >=20 > --tony >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 25 05:07:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYJWI-0006cT-6P; Tue, 25 Apr 2006 05:07:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYJWH-0006cO-D2 for enum@ietf.org; Tue, 25 Apr 2006 05:07:41 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYJWG-00035c-4v for enum@ietf.org; Tue, 25 Apr 2006 05:07:41 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 18185210088; Tue, 25 Apr 2006 11:07:39 +0200 (CEST) Message-ID: <444DE6DA.3000908@pernau.at> Date: Tue, 25 Apr 2006 11:07:38 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Tony Rutkowski Subject: Re: [Enum] RE: ENUM Working Group Last call on Infrastructure ENUM Requirements References: <4425AD81.1090805@shockey.us> <34DA635B184A644DA4588E260EC0A25A0CA3FB49@ACCLUST02EVS1.ugd.att.com> <7.0.1.0.2.20060424192320.02af53d8@verisign.com> In-Reply-To: <7.0.1.0.2.20060424192320.02af53d8@verisign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: enum@ietf.org, ppfautz@att.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Tony Rutkowski wrote: > 47 CFR Part 52 to Hi Tony! Could you please explain your abbreviations? regards klaus _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 25 05:55:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYKGi-0002dJ-8J; Tue, 25 Apr 2006 05:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYKGg-0002dE-Ub for enum@ietf.org; Tue, 25 Apr 2006 05:55:38 -0400 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYKGf-00061g-NZ for enum@ietf.org; Tue, 25 Apr 2006 05:55:38 -0400 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id k3PA0Wt9030356; Tue, 25 Apr 2006 06:00:33 -0400 Received: from dul1trutkow-l1.verisign.com ([10.26.0.233]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 05:55:34 -0400 Message-Id: <7.0.1.0.2.20060425095824.029b71b8@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 25 Apr 2006 10:55:27 +0100 To: "Stastny Richard" , From: Tony Rutkowski Subject: Re: [Enum] RE: ENUM Working Group Last call on InfrastructureENUM Requirements In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C49B0@oefeg-s04.oefeg.loc > References: <32755D354E6B65498C3BD9FD496C7D462C49B0@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 25 Apr 2006 09:55:35.0361 (UTC) FILETIME=[65F01B10:01C6684E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, >if you post such cryptic numbers and letters (47 CFR Part 52) on >this list, coild >you please be more specific > >You should also consider that the IETF is a global standards body and >that there are some 200+ other countries out there Apologies for the U.S.-centric reference. Part 52 of the FCC's regulations establish the basis for exclusive authority, administrative mechanisms, and substantive requirements for the use of E.164 numbers in the U.S. http://www.access.gpo.gov/nara/cfr/waisidx_05/47cfr52_05.html The remark was intended to raise the challenge of devising any "Infrastructure ENUM Requirements" in an IETF document, including definitions, when the actual authority to articulate just about everything in the document resides with national regulatory authorities. Typically, to produce what is contained in the document, must be undertaken through a public rule making or consultative process. Few, if any, have done so. While writing an IETF draft document on infrastructure ENUM may have some useful benefit among the participants, the actual implementation of the desired E.164 resolver capabilities as part of national infrastructures will require the national authority to undertake a proceeding to accomplish this task. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 25 08:35:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYMlJ-0007Hy-14; Tue, 25 Apr 2006 08:35:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYMlH-0007Ho-46 for enum@ietf.org; Tue, 25 Apr 2006 08:35:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYLBb-0007c6-7x for enum@ietf.org; Tue, 25 Apr 2006 06:54:27 -0400 Received: from peregrine.verisign.com ([216.168.239.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYKzS-0007d3-SP for enum@ietf.org; Tue, 25 Apr 2006 06:41:56 -0400 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id k3PAk3PV014303; Tue, 25 Apr 2006 06:46:03 -0400 Received: from dul1trutkow-l1.verisign.com ([10.26.0.233]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 06:41:51 -0400 Message-Id: <7.0.1.0.2.20060425112553.02ae23e0@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 25 Apr 2006 11:41:43 +0100 To: "Stastny Richard" , From: Tony Rutkowski Subject: RE: [Enum] RE: ENUM Working Group Last call on InfrastructureENUM Requirements In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4F02@oefeg-s04.oefeg.loc > References: <32755D354E6B65498C3BD9FD496C7D463C4F02@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 25 Apr 2006 10:41:51.0585 (UTC) FILETIME=[DCB24510:01C66854] X-Spam-Score: -2.6 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, >It is understood that the definition of carrier-of-record within a > given jurisdiction is subject to modification by national > authorities. A lot more than just carrier-of-record is subject to change. What I'm saying is that the entire document constitutes regulatory policy within the purview and authority of national regulatory authorities, or business options within the purview of providers in a competitive marketplace. There is little technical content in the document. Furthermore, some aspects seem purposely anticompetitive, e.g., specifying IRIS for maintaining subscriber information rather than E.115-2005 which provides equal or better functionality, and in fact is probably necessary under the EU and national authentication and data retention directives. The adoption of this kind of draft while well intended, seems a bad precedent for the IETF and undertakes decisions properly within the purview of national authorities or the marketplace. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 25 08:47:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYMwg-00031D-C6; Tue, 25 Apr 2006 08:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYMwf-000317-AZ for enum@ietf.org; Tue, 25 Apr 2006 08:47:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYLCj-0007c6-PY for enum@ietf.org; Tue, 25 Apr 2006 06:55:37 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FYKTz-0007IX-CL for enum@ietf.org; Tue, 25 Apr 2006 06:09:25 -0400 Content-class: urn:content-classes:message Subject: RE: [Enum] RE: ENUM Working Group Last call on InfrastructureENUM Requirements MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Apr 2006 12:13:19 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4F02@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE: ENUM Working Group Last call on InfrastructureENUM Requirements Thread-Index: AcZoTvp+4k7HxIlSQvizPnpnFUt2oAAAOhSQ From: "Stastny Richard" To: "Tony Rutkowski" , X-Spam-Score: -2.4 (--) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > the > actual implementation of the desired E.164 resolver capabilities > as part of national infrastructures will require the national > authority to undertake a proceeding to accomplish this task. Yes, and is clearly stated in the draft: It is understood that the definition of carrier-of-record within a given jurisdiction is subject to modification by national authorities. If you would like another wording, please propose ASAP This document is WGLC and we need precise proposals In the new draft-ietf-enum-infrastructure-00.txt it is also stated: Infrastructure ENUM Tier 2 resource records in the Infrastructure=20 ENUM tree would be controlled by the service provider that is=20 providing services to a given E.164 number, generally referred to in=20 various nations as the "carrier of record". The definition of who=20 controls a given E.164 number is a national matter or is defined by=20 the entity controlling the numbering space. =20 And: The IAB is to coordinate with ITU-T Telecommunication Standardization=20 Bureau (TSB) if the technical contact for the domain ie164.arpa is to change, as ITU-T TSB has an operational working relationship with=20 this technical contact which needs to be reestablished. Delegations=20 in the zone ie164.arpa (not delegations in delegated domains of=20 ie164.arpa) should be done after Expert Review, and the IESG will=20 appoint a designated expert. This implies that the procedure within a country is exactly the same like in User ENUM. Richard > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com] > Sent: Tuesday, April 25, 2006 11:55 AM > To: Stastny Richard; ppfautz@att.com > Cc: enum@ietf.org > Subject: Re: [Enum] RE: ENUM Working Group Last call on InfrastructureENUM > Requirements >=20 > Hi Richard, >=20 > >if you post such cryptic numbers and letters (47 CFR Part 52) on > >this list, coild > >you please be more specific > > > >You should also consider that the IETF is a global standards body and > >that there are some 200+ other countries out there >=20 > Apologies for the U.S.-centric reference. Part 52 of > the FCC's regulations establish the basis for exclusive > authority, administrative mechanisms, and substantive > requirements for the use of E.164 numbers in the U.S. > http://www.access.gpo.gov/nara/cfr/waisidx_05/47cfr52_05.html >=20 > The remark was intended to raise the challenge of devising > any "Infrastructure ENUM Requirements" in an IETF document, > including definitions, when the actual authority to articulate > just about everything in the document resides with national > regulatory authorities. Typically, to produce what is contained > in the document, must be undertaken through a public rule > making or consultative process. Few, if any, have done so. >=20 > While writing an IETF draft document on infrastructure ENUM > may have some useful benefit among the participants, the > actual implementation of the desired E.164 resolver capabilities > as part of national infrastructures will require the national > authority to undertake a proceeding to accomplish this task. >=20 > --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 25 09:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNED-0008IP-6y; Tue, 25 Apr 2006 09:05:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNEB-0008IK-BN for enum@ietf.org; Tue, 25 Apr 2006 09:05:15 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FYNE9-0006uA-Rx for enum@ietf.org; Tue, 25 Apr 2006 09:05:15 -0400 Content-class: urn:content-classes:message Subject: RE: [Enum] RE: ENUM Working Group Last call on InfrastructureENUM Requirements MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Apr 2006 15:09:13 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4F08@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE: ENUM Working Group Last call on InfrastructureENUM Requirements Thread-Index: AcZoZVbS7t6Yr+1LSXeO+Cjhf21OMgAAZwdA From: "Stastny Richard" To: "Tony Rutkowski" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Tony, IMHO Infrastructure ENUM is easier to handle then=20 User ENUM, and User ENUM is already discussed all over the place. I also think that you are barking up the wrong tree: the real problem in future that has to be solved is VoIP Peeing and IP Interconnect and this problem is only loosely coupled with E.164 numbers via ENUM In the TDM world there are established "Technology neutral" ;-) rules for Interconnect both national and international. IP Interconnect and also Interconnect on lower layers are not (yet) regulated and here the regime has developed by competition and tradition and is working quite well, Both national and international (lets not go into details here) Now with VoIP Interconnect technically we have an overlay of a regulated regime on top of an unregulated regime, and this causes serious problems in all directions. One (bell-head) fraction is trying to impose the regulated regime also on the un-regulated layers, the other (net-head) fraction tries to extend the un-regulated regime also to the regulated part. To peer between VoIP providers (whatever that is) you do not need E.164 numbers and the NANPA etc., you use basically=20 domain names (SIP URIs) which are also quite unregulated. VOIP Peering also needs to be solved on a global scale AND on an e2e scale. There is no real distinctions anymore between User-Network-Interfaces (UNI), national Network-networks interfaces (NNI, PoI) and international gateways. E.164 numbers and ENUm are only applets to these basic issues. The discussion on the MS monopoly is also about the OS and not about the 7th applet from the left in Outlook. Regards Richard > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com] > Sent: Tuesday, April 25, 2006 12:42 PM > To: Stastny Richard; ppfautz@att.com > Cc: enum@ietf.org > Subject: RE: [Enum] RE: ENUM Working Group Last call on InfrastructureENUM > Requirements >=20 > Hi Richard, >=20 > >It is understood that the definition of carrier-of-record within a > > given jurisdiction is subject to modification by national > > authorities. >=20 > A lot more than just carrier-of-record is subject to change. >=20 > What I'm saying is that the entire document constitutes > regulatory policy within the purview and authority of national > regulatory authorities, or business options within the purview > of providers in a competitive marketplace. There is little > technical content in the document. >=20 > Furthermore, some aspects seem purposely anticompetitive, > e.g., specifying IRIS for maintaining subscriber information > rather than E.115-2005 which provides equal or better > functionality, and in fact is probably necessary under the > EU and national authentication and data retention directives. >=20 > The adoption of this kind of draft while well intended, > seems a bad precedent for the IETF and undertakes > decisions properly within the purview of national > authorities or the marketplace. >=20 > --tony >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 25 09:08:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNHB-00016e-2b; Tue, 25 Apr 2006 09:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNH8-00016Z-SD for enum@ietf.org; Tue, 25 Apr 2006 09:08:18 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYNH6-00077W-HG for enum@ietf.org; Tue, 25 Apr 2006 09:08:18 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FYNGz-0000fU-HJ; Tue, 25 Apr 2006 08:08:10 -0500 From: "Brian Rosen" To: "'Tony Rutkowski'" , "'Stastny Richard'" , Subject: RE: [Enum] RE: ENUM Working Group Last call onInfrastructureENUM Requirements Date: Tue, 25 Apr 2006 09:08:11 -0400 Message-ID: <04d901c66869$5014e800$6901a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7.0.1.0.2.20060425095824.029b71b8@verisign.com> Thread-Index: AcZoTmzgS3BREpJ/RL6d7bFhyOaEBgAGZT/w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org It would seem you are confusing implementation of any type of enum with IETF practice on how a single global standard for enum is produced. I do not recall any prior restraint of international standards work for national regulatory action. I fail to see any difference between infrastructure enum and user enum from a regulatory point of view. I don't recall the FCC requiring actual rule making to allow user enum, which certainly affects the use of e.164 numbers in the U.S., and I don't expect any regulatory action affecting infrastructure enum. Actually, since infrastructure enum more closely represents current carrier practice than user enum does, I would have expected any regulatory action on that before we would see any on infrastructure enum. However, the FCC seems content to allow the current process to continue without action. I'd expect the same of infrastructure enum. Of course, predicting what any government agency will do is, ah, challenging, IANAL and thus YMMV. Brian -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@verisign.com] Sent: Tuesday, April 25, 2006 5:55 AM To: Stastny Richard; ppfautz@att.com Cc: enum@ietf.org Subject: Re: [Enum] RE: ENUM Working Group Last call onInfrastructureENUM Requirements Hi Richard, >if you post such cryptic numbers and letters (47 CFR Part 52) on >this list, coild >you please be more specific > >You should also consider that the IETF is a global standards body and >that there are some 200+ other countries out there Apologies for the U.S.-centric reference. Part 52 of the FCC's regulations establish the basis for exclusive authority, administrative mechanisms, and substantive requirements for the use of E.164 numbers in the U.S. http://www.access.gpo.gov/nara/cfr/waisidx_05/47cfr52_05.html The remark was intended to raise the challenge of devising any "Infrastructure ENUM Requirements" in an IETF document, including definitions, when the actual authority to articulate just about everything in the document resides with national regulatory authorities. Typically, to produce what is contained in the document, must be undertaken through a public rule making or consultative process. Few, if any, have done so. While writing an IETF draft document on infrastructure ENUM may have some useful benefit among the participants, the actual implementation of the desired E.164 resolver capabilities as part of national infrastructures will require the national authority to undertake a proceeding to accomplish this task. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 25 09:20:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNSn-0004pz-Mf; Tue, 25 Apr 2006 09:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNSm-0004pu-8w for enum@ietf.org; Tue, 25 Apr 2006 09:20:20 -0400 Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYNSj-00089Q-PN for enum@ietf.org; Tue, 25 Apr 2006 09:20:20 -0400 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Tue, 25 Apr 2006 16:30:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: ENUM Working Group Last call on InfrastructureENUMRequirements Date: Tue, 25 Apr 2006 16:20:15 +0300 Message-ID: <07BC6C0D40216E44A34BE6701694FE86038B452E@POSTI.laru.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] RE: ENUM Working Group Last call on InfrastructureENUMRequirements Thread-Index: AcZoZVbS7t6Yr+1LSXeO+Cjhf21OMgAAZwdAAACwOmA= From: "Nieminen Klaus" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi all, I just want to give you one NRA's opinion. As Richard said the Infrastructure ENUM is easier for us to handle than the User ENUM and that we do not believe that there are any relevant regulatory issues concerning the requirements document. I believe that, if there are any actual requlatory requirements, they should be taken into account. However, I have not seen any concrete requirements yet. regards, - Klaus - ___________________________________________ KLAUS NIEMINEN Senior Adviser Finnish Communications Regulatory Authority=20 Internet and Information Security P.O. Box 313 FIN-00181 HELSINKI, FINLAND tel.: +358 9 6966 634 fax: +358 9 6966 873 e-mail: klaus.nieminen@ficora.fi www: http://www.ficora.fi=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 25 09:34:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNgc-00019G-40; Tue, 25 Apr 2006 09:34:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNga-00019B-Bp for enum@ietf.org; Tue, 25 Apr 2006 09:34:36 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYNgZ-0000Rr-36 for enum@ietf.org; Tue, 25 Apr 2006 09:34:36 -0400 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Tue, 25 Apr 2006 15:29:24 +0200 id 00004006.444E2434.0000785B Message-ID: <444E242B.9050301@enum.at> Date: Tue, 25 Apr 2006 15:29:15 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] RE: ENUM Working Group Last call on InfrastructureENUM Requirements References: <32755D354E6B65498C3BD9FD496C7D463C4F08@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4F08@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: enum@ietf.org, ppfautz@att.com, Tony Rutkowski X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Stastny Richard wrote: > the real problem in future that has to be solved is VoIP > Peeing and IP Interconnect ... ^^^^^^ is adhoc then some kind of incontinence? ;) rotfl. alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 25 13:57:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYRmX-0007j6-SX; Tue, 25 Apr 2006 13:57:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYRmX-0007j0-5H; Tue, 25 Apr 2006 13:57:01 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYRmV-0005m9-BJ; Tue, 25 Apr 2006 13:57:01 -0400 Received: from [10.31.13.102] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k3PHtJkW020289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Apr 2006 10:55:20 -0700 Message-ID: <444E6268.1020805@shockey.us> Date: Tue, 25 Apr 2006 13:54:48 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: iesg-secretary@ietf.org, Cullen Jennings , "Peterson, Jon" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , enum@ietf.org Content-Type: multipart/mixed; boundary="------------080907020301070103060008" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: c8e71861e926d70c1bd2436e580ecf31 Cc: Subject: [Enum] Request for Publication - draft-ietf-enum-validation-epp-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------080907020301070103060008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is a request for publication for one IETF ENUM WG working group document. A two week WG last call on this document concluded on April 12, 2006. The document listed below is being proposed for Proposed Standard. This document incorporates comments from the last call. Status - Proposed Standard Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-ietf-enum-validation-epp-03.txt Pages : 26 Date : 2006-2-15 This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-epp-03.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------080907020301070103060008 Content-Type: application/msword; name="PROTO_draft_ietf_enum_validation_epp_Final.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="PROTO_draft_ietf_enum_validation_epp_Final.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPAAAAAAA AAAAEAAAPgAAAAEAAAD+////AAAAADsAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEANyAJBAAA+BK/AAAAAAAAEAAAAAAABAAA PBgAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAAAAAJBBYAIiYAADd8AAA3fAAAPBQAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAGwAAAAAAIoEAAAAAAAAigQAAIoEAAAAAAAAigQAAAAAAACKBAAA AAAAAIoEAAAAAAAAigQAABQAAAAAAAAAAAAAAJ4EAAAAAAAAvAoAAAAAAAC8CgAAAAAAALwK AAAAAAAAvAoAAAwAAADICgAAJAAAAJ4EAAAAAAAA/xcAAPABAAD4CgAAKAAAACALAAAAAAAA IAsAAAAAAAAgCwAAAAAAACALAAAAAAAAIAsAAAAAAAAgCwAAAAAAACALAAAAAAAAfhcAAAIA AACAFwAAAAAAAIAXAAAAAAAAgBcAAAAAAACAFwAAAAAAAIAXAAAAAAAAgBcAACQAAADvGQAA IAIAAA8cAACAAAAApBcAABUAAAAAAAAAAAAAAAAAAAAAAAAAigQAAAAAAAAgCwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAgCwAAAAAAACALAAAAAAAAIAsAAAAAAAAgCwAAAAAAAKQXAAAAAAAA nAwAAAAAAACKBAAAAAAAAIoEAAAAAAAAIAsAAAAAAAAAAAAAAAAAACALAAAAAAAAuRcAABYA AACcDAAAAAAAAJwMAAAAAAAAnAwAAAAAAAAgCwAAmgAAAIoEAAAAAAAAIAsAAAAAAACKBAAA AAAAACALAAAAAAAAfhcAAAAAAAAAAAAAAAAAAJwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAsAAAAAAAB+FwAAAAAAAJwMAACQAAAA nAwAAAAAAAAsDQAAjgAAAOgWAABoAAAAigQAAAAAAACKBAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfhcAAAAAAAAgCwAA AAAAAOwKAAAMAAAAoLXHPpFoxgGeBAAAHgYAALwKAAAAAAAAugsAAOIAAABQFwAAHgAAAAAA AAAAAAAAfhcAAAAAAADPFwAAMAAAAP8XAAAAAAAAbhcAABAAAACPHAAAAAAAAJwMAAAAAAAA jxwAAAAAAAB+FwAAAAAAAJwMAAAAAAAAngQAAAAAAACeBAAAAAAAAIoEAAAAAAAAigQAAAAA AACKBAAAAAAAAIoEAAAAAAAAAgDZAAAAV0cgQ2hhaXIgV3JpdGUtVXAgZm9yIFB1YmxpY2F0 aW9uIFJlcXVlc3QNV29ya2luZyBHcm91cDogVGVsZXBob25lIE51bWJlciBNYXBwaW5nICBb RU5VTX0NDVRpdGxloCA6ICBFTlVNIFZhbGlkYXRpb24gSW5mb3JtYXRpb24gTWFwcGluZyBm b3IgdGhlIEV4dGVuc2libGUgUHJvdmlzaW9uaW5nIFByb3RvY29sDQ0NQXV0aG9yKHMpoKCg IDogQi4gSG9lbmVpc2VuDUZpbGVuYW1loKCgIDogZHJhZnQtaWV0Zi1lbnVtLXZhbGlkYXRp b24tZXBwLTAzDVNoZXBhcmRpbmcgV0cgQ2hhaXI6IFJpY2hhcmQgU2hvY2tleQ0NTGFzdCBD YWxsIENvbXBsZXRlZDoNDU5JVFMgcmV2aWV3IHByZWZvcm1lZCBieTogQWxleGFuZGVyIE1h eXJob2ZlciA8QWxleGFuZGVyLm1heXJob2ZlckBlbnVtLmF0Pg1IYXZlIHRoZSBjaGFpcnMg cGVyc29uYWxseSByZXZpZXdlZCB0aGlzIHZlcnNpb24gb2YgdGhlIEludGVybmV0IERyYWZ0 IChJRCksIGFuZCBpbiBwYXJ0aWN1bGFyLCBkbyB0aGV5IGJlbGlldmUgdGhpcyBJRCBpcyBy ZWFkeSB0byBmb3J3YXJkIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbj8NWWVzIHRoZSBk b2N1bWVudCBoYXMgYmVlbiByZXZpZXdlZCBieSB0aGUgV0cgY2hhaXJzLg1IYXMgdGhlIGRv Y3VtZW50IGhhZCBhZGVxdWF0ZSByZXZpZXcgZnJvbSBib3RoIGtleSBXRyBtZW1iZXJzIGFu ZCBrZXkgbm9uLVdHIG1lbWJlcnM/IA1ZZXMsIHRoZSBkb2N1bWVudCB3YXMgcmV2aWV3ZWQg YnkgV0cgbWVtYmVycyBhcyB3ZWxsIGFzIG90aGVyIHBlcnNvbnMuIFRoZSBjb25jZXB0cyBy ZXByZXNlbnRlZCBpbiB0aGlzIGRvY3VtZW50IGhhdmUgaW5mbHVlbmNlIG9uIG90aGVyIGRv Y3VtZW50cyBpbiB0aGUgRU5VTSBzY2VuZS4gSW4gYWRkaXRpb24sIHRocmVlIHByZXNlbnRh dGlvbnMgb24gcmVjZW50IElFVEYgbWVldGluZ3MgYWJvdXQgdGhlIGRvY3VtZW50IHdlcmUg Z2l2ZW4uDURvIHlvdSBoYXZlIGFueSBjb25jZXJucyBhYm91dCB0aGUgZGVwdGggb3IgYnJl YWR0aCBvZiB0aGUgcmV2aWV3cyB0aGF0IGhhdmUgYmVlbiBwZXJmb3JtZWQ/DVRoZXJlIGFy ZSBubyBjb25jZXJucyBhYm91dCBkZXB0aCBvciBicmVhZHRoIG9mIHRoZSByZXZpZXdzLiAN RG8geW91IGhhdmUgY29uY2VybnMgdGhhdCB0aGUgZG9jdW1lbnQgbmVlZHMgbW9yZSByZXZp ZXcgZnJvbSBhIHBhcnRpY3VsYXIgKGJyb2FkZXIpIHBlcnNwZWN0aXZlIChlLmcuLCBzZWN1 cml0eSwgb3BlcmF0aW9uYWwgY29tcGxleGl0eSwgc29tZW9uZSBmYW1pbGlhciB3aXRoIEFB QSwgZXRjLik/DU5vdCByZWFsbHkuIE1heWJlIHNvbWUgRVBQIGV4cGVydHMgY291bGQgaGF2 ZSBhIGxvb2sgb24gdGhlIGZpbmFsIHZlcnNpb24gb2YgdGhpcyBkcmFmdC4NRG8geW91IGhh dmUgYW55IHNwZWNpZmljIGNvbmNlcm5zL2lzc3VlcyB3aXRoIHRoaXMgZG9jdW1lbnQgdGhh dCB5b3UgYmVsaWV2ZSB0aGUgQURzIGFuZC9vciBJRVNHIHNob3VsZCBiZSBhd2FyZSBvZj8g Rm9yIGV4YW1wbGUsIHBlcmhhcHMgeW91IGFyZSB1bmNvbWZvcnRhYmxlIHdpdGggY2VydGFp biBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yIGhhdmUgY29uY2VybnMgd2hldGhlciB0aGVy ZSByZWFsbHkgaXMgYSBuZWVkIGZvciBpdC4gSW4gYW55IGV2ZW50LCBpZiB5b3VyIGlzc3Vl cyBoYXZlIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBXRyBhbmQgdGhlIFdHIGhhcyBpbmRpY2F0 ZWQgaXQgdGhhdCBpdCBzdGlsbCB3aXNoZXMgdG8gYWR2YW5jZSB0aGUgZG9jdW1lbnQsIGRl dGFpbCB0aG9zZSBjb25jZXJucyBpbiB0aGUgd3JpdGUtdXAuDU5vIGNvbmNlcm5zLiANSG93 IHNvbGlkIGlzIHRoZSBXRyBjb25zZW5zdXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQ/IERvZXMg aXQgcmVwcmVzZW50IHRoZSBzdHJvbmcgY29uY3VycmVuY2Ugb2YgYSBmZXcgaW5kaXZpZHVh bHMsIHdpdGggb3RoZXJzIGJlaW5nIHNpbGVudCwgb3IgZG9lcyB0aGUgV0cgYXMgYSB3aG9s ZSB1bmRlcnN0YW5kIGFuZCBhZ3JlZSB3aXRoIGl0Pw1UaGUgbWFqb3JpdHkgb2YgdGhlIHdv cmtpbmcgZ3JvdXAgbWVtYmVycyBoYXZlIGV4cHJlc3NlZCB0aGVpciBhcHByZWNpYXRpb24g b2YgdGhlIGRvY3VtZW50LiBTdWdnZXN0aW9ucyBmcm9tIG1lbWJlcnMgaGF2ZSBiZWVuIGlu Y29ycG9yYXRlZCBpbnRvIHRoZSBkb2N1bWVudC4NSGFzIGFueW9uZSB0aHJlYXRlbmVkIGFu IGFwcGVhbCBvciBvdGhlcndpc2UgaW5kaWNhdGVkIGV4dHJlbWUgZGlzY29udGVudD8gSWYg c28sIHBsZWFzZSBzdW1tYXJpc2UgdGhlIGFyZWFzIG9mIGNvbmZsaWN0IGluIHNlcGFyYXRl IGVtYWlsIHRvIHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yLg1ObywgdGhlcmUgYXJl IG5vIGtub3duIHRocmVhdHMgdG8gYXBwZWFsLiANSGF2ZSB0aGUgY2hhaXJzIHZlcmlmaWVk IHRoYXQgdGhlIGRvY3VtZW50IGFkaGVyZXMgdG8gYWxsIG9mIHRoZSATIEhZUEVSTElOSyAi aHR0cDovL3d3dy5pZXRmLm9yZy9JRC1DaGVja2xpc3QuaHRtbCIBFElEIENoZWNrbGlzdCBp dGVtcxUgPw1BIE5JVCByZXZpZXcgd2FzIHBlcmZvcm1lZCBieSB0aGUgd29ya2luZyBncm91 cCBzZWNyZXRhcnkgb24gTU1NIERELCAyMDA2LiBUaGUgcmV2aXNlZCBkb2N1bWVudCB3YXMg Y2hlY2tlZCBhZ2FpbiBvbiBNTU0gREQsIDIwMDYuDUlzIHRoZSBkb2N1bWVudCBzcGxpdCBp bnRvIG5vcm1hdGl2ZSBhbmQgaW5mb3JtYXRpdmUgcmVmZXJlbmNlcz8gQXJlIHRoZXJlIG5v cm1hdGl2ZSByZWZlcmVuY2VzIHRvIElEcywgd2hlcmUgdGhlIElEcyBhcmUgbm90IGFsc28g cmVhZHkgZm9yIGFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhciBz dGF0ZT8gKG5vdGUgaGVyZSB0aGF0IHRoZSBSRkMgZWRpdG9yIHdpbGwgbm90IHB1Ymxpc2gg YW4gUkZDIHdpdGggbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gSURzLCBpdCB3aWxsIGRlbGF5 IHB1YmxpY2F0aW9uIHVudGlsIGFsbCBzdWNoIElEcyBhcmUgYWxzbyByZWFkeSBmb3IgcHVi bGljYXRpb24gYXMgUkZDcy4pDVJlZmVyZW5jZXMgYXJlIHByb3Blcmx5IHNwbGl0LCB0aGVy ZSBhcmUgbm8gbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gSURzLg1Ib3dldmVyLCB0aGVyZSBh cmUgdHdvIG5vbi1ub3JtYXRpdmUgcmVmZXJlbmNlcyB0byBJRHM6DWRyYWZ0LWlldGYtZW51 bS12YWxpZGF0aW9uLWFyY2ggKFB1YmxpY2F0aW9uIFJlcXVlc3RlZCkNZHJhZnQtaWV0Zi1l bnVtLXZhbGlkYXRpb24tdG9rZW4gKBMgSFlQRVJMSU5LICJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL3B1YmxpYy9waWR0cmFja2VyLmNnaT9jb21tYW5kPXZpZXdfc3RhdGVfZGVz YyZpZD0xMDAiARRJLUQgRXhpc3RzFSksDVdoYXQgaXMgdGhlIGludGVuZGVkIHN0YXR1cyBv ZiB0aGUgZG9jdW1lbnQ/IChlLmcuLCBQcm9wb3NlZCBTdGFuZGFyZCwgSW5mb3JtYXRpb25h bD8pDVRoZSBpbnRlbmRlZCBzdGF0dXMgaXMgUHJvcG9zZWQgU3RhbmRhcmQuDUZvciBTdGFu ZGFyZHMgVHJhY2sgYW5kIEJDUCBkb2N1bWVudHMsIHRoZSBJRVNHIGFwcHJvdmFsIGFubm91 bmNlbWVudCBpbmNsdWRlcyBhIHdyaXRlLXVwIHNlY3Rpb24gd2l0aCB0aGUgZm9sbG93aW5n IHNlY3Rpb25zOiANVGVjaG5pY2FsIFN1bW1hcnkNV29ya2luZyBHcm91cCBTdW1tYXJ5DVBy b3RvY29sIFF1YWxpdHkNVGVjaG5pY2FsIFN1bW1hcnkgKFNhbWUgYXMgQWJzdHJhY3QpOg0N ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gRXh0ZW5zaWJsZSBQcm92aXNpb25pbmcg UHJvdG9jb2wgKEVQUCkgIGV4dGVuc2lvbiBmcmFtZXdvcmsgZm9yIG1hcHBpbmcgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIHZhbGlkYXRpb24gIHByb2Nlc3MgdGhhdCBoYXMgYmVlbiBhcHBs aWVkIGZvciB0aGUgRS4xNjQgbnVtYmVyIChvciBudW1iZXIgcmFuZ2UpLCB3aGljaCB0aGUg RS4xNjQgTnVtYmVyIE1hcHBpbmcgKEVOVU0pIGRvbWFpbiBuYW1lIGlzIGJhc2VkIG9uLiAg U3BlY2lmaWVkIGluIHRoZSBFeHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFnZSAoWE1MKSwgdGhp cyBtYXBwaW5nIGV4dGVuZHMgdGhlIEVQUCBkb21haW4gbmFtZSBtYXBwaW5nIHRvIHByb3Zp ZGUgYW4gYWRkaXRpb25hbCBmZWF0dXJlICAgcmVxdWlyZWQgZm9yIHRoZSBwcm92aXNpb25p bmcgb2YgRU5VTSBkb21haW4gbmFtZXMuDQ1Xb3JraW5nIEdyb3VwIFN1bW1hcnk6DQ1ObyBj b250cm92ZXJzaWFsIGlzc3VlcyB3aXRoIHRoZSB0aGlzIGRvY3VtZW50Lg0NDVByb3RvY29s IFF1YWxpdHk6DQ1BcmUgdGhlcmUgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBw cm90b2NvbD8NDVRoZXJlIGlzIG9uZSBrbm93biBzZXJ2ZXIgaW1wbGVtZW50YXRpb246DVNX SVRDSC5jaA0NVGhlcmUgYXJlIHRocmVlIGtub3duIGNsaWVudCBpbXBsZW1lbnRhdGlvbnM6 DVNXSVRDSC5jaA1jeWJlcmVudW0uY2gNc3dpc3NlbnVtLmNoDQ1UaGUgQ2xpZW50IGltcGxl bWVudGF0aW9ucyBpbnRlci1vcGVyYXRlIHdpdGggdGhlIHNlcnZlciBpbXBsZW1lbnRhdGlv biBpbiB0aGUgU3dpc3MgRU5VTSBUcmlhbC4gDQ1IYXZlIGEgc2lnbmlmaWNhbnQgbnVtYmVy IG9mIHZlbmRvcnMgaW5kaWNhdGVkIHRoZXkgcGxhbiB0byBpbXBsZW1lbnQgdGhlIHNwZWNp ZmljYXRpb24/DQ1SZWdpc3RyYXJzIGZvciAxLjQuZTE2NC5hcnBhLiB3aWxsIGhhdmUgdG8g aW1wbGVtZW50IHRoaXMsICh1bmxlc3MgdGhleSB1c2UgdGhlIHRvb2xraXQgU3dpdGNoIGlz IHByb3ZpZGluZykuDQ1JdCBtaWdodCBiZSwgdGhhdCBlbnVtLmF0IGlzIGRlY2lkaW5nIHRv IGltcGxlbWVudCB0aGlzIGludG8gdGhlaXIgRU5VTSBzZXJ2ZXIgYXQgc29tZSBwb2ludCBp biB0aW1lLg0NQXJlIHRoZXJlIGFueSByZXZpZXdlcnMgdGhhdCBtZXJpdCBzcGVjaWFsIG1l bnRpb24gYXMgaGF2aW5nIGRvbmUgYSB0aG9yb3VnaCByZXZpZXcgKGkuZS4sIHRoYXQgcmVz dWx0ZWQgaW4gaW1wb3J0YW50IGNoYW5nZXMgb3IgYSBjb25jbHVzaW9uIHRoYXQgdGhlIGRv Y3VtZW50IGhhZCBubyBzdWJzdGFudGl2ZSBpc3N1ZXMpPw1BbGV4YW5kZXIgTWF5cmhvZmVy IGhhZCBhIHRob3JvdWdoIHJldmlldyBhbmQgcHJvdmlkZWQgc3Vic3RhbnRpYWwgZmVlZGJh Y2ssIHdoaWNoIGhhcyBiZWVuIGluY29ycG9yYXRlZCBpbnRvIHRoZSBkb2N1bWVudC4gTm8g c3Vic3RhbnRpdmUgaXNzdWVzLg0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABbBAAAswQAAIgF AAAxBgAAZgYAAL0GAAC7BwAAGAgAAFYIAAACCQAAWwkAAAMLAAARCwAA1gsAAHYMAAAjDQAA Tg0AAI8NAACQDQAAwg0AAMMNAADEDQAA1g0AANcNAADaDQAAXQ4AAMsPAACmEAAApxAAAAUR AAAGEQAABxEAABERAAASEQAAFREAAGwRAACWEQAAdRIAAAgUAAA/FAAAQBQAAFcUAACKFAAA nBQAADwYAAAA/AD8APwA/AD8APwA/AD8APz0/On04/T8APwA3gDW3tPeAPwA/ADOxfwA/AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAQQ0oUAFBKAwBeSgMAYUoUAAAIUEoDAGFKFAAABDBKFAAADwIIgQNqvQAAAAYIAVUIAQkD agAAAABVCAEKMEoUADUIgVwIgQAVAgiBA2oAAAAABggBNQiBVQgBXAiBDwNqAAAAADUIgVUI AVwIgQY1CIFcCIEtAAQAACoEAABaBAAAWwQAALIEAACzBAAAtAQAANAEAAAABQAAJQUAACYF AAA7BQAAPAUAAIgFAAAxBgAAZgYAAL0GAAC7BwAAGAgAAFYIAAACCQAAWwkAAAMLAAARCwAA 1gsAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA AADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA AAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA1gAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADWAAAA AAAAAAAAAAAA3AAAAAAAAAAAAAAAANYAAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA1gAAAAAA AAAAAAAAANwAAAAAAAAAAAAAAADWAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABQAAE6QYARSkGAEVAAAKJgALRgEADcYFAAHQAgAPhNACEYSY/hOkGAEUpBgB XoTQAmCEmP4ABRoAE6QAABSkAAAAAQAAAAECAAADAQATpAAAABgABAAAPBgAAP0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQEAAEBAdYLAAB2DAAAIw0AAE4NAADaDQAAXQ4AAMsPAAAUEAAATBAAAIQQAAAVEQAA bBEAAJYRAAAWEgAAKBIAAD4SAABPEgAAdRIAAPkAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADkAAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAL4AAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAArQAAAAAA AAAAAAAAAJoAAAAAAAAAAAAAAACYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARkAEwAACiYB C0YBAA3GBQABoAUAD4SgBRGEmP4UpBgBXoSgBWCEmP4RAAAKJgELRgEADcYFAAGgBQAPhKAF EYSY/l6EoAVghJj+EwAACiYAC0YBAA3GBQAB0AIAD4TQAhGEmP4TpBgBXoTQAmCEmP4RAAAK JgALRgIADcYFAAHQAgAPhNACEYSY/l6E0AJghJj+AAEAABUAAAomAAtGAQANxgUAAdACAA+E 0AIRhJj+E6QYARSkGAFehNACYISY/gAFAAATpBgBFKQYAQARdRIAAHYSAAA/FAAAQBQAAFcU AABYFAAAiBQAAIkUAACKFAAAnBQAAJ0UAADRFAAA0hQAAPwUAAAGFQAABxUAADUVAAA/FQAA TBUAAFkVAABaFQAAvBUAAL0VAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAA AOQAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAAwgAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADT AAAAAAAAAAAAAAAAwgAAAAAAAAAAAAAAAMIAAAAAAAAAAAAAAADCAAAAAAAAAAAAAAAA+wAA AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAAomAQtG BAANxgUAATgEAA+EOAQRhJj+XoQ4BGCEmP4RAAAKJgALRgQADcYFAAHQAgAPhNACEYSY/l6E 0AJghJj+AAUAAA+E0AJehNACEQAACiYBC0YBAA3GBQABoAUAD4SgBRGEmP5ehKAFYISY/gAB AAAAARkAABa9FQAAFhYAABcWAACFFgAAhhYAAOwWAADtFgAAqRcAADwYAADuAAAAAAAAAAAA AAAA7AAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAA AOwAAAAAAAAAAAAAAADCAAAAAAAAAAAAAAAAvgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAADAAAUpBgBEwAACiYBC0YBAA3GBQABoAUAD4SgBRGEmP4UpBgBXoSgBWCE mP4ABQAAD4TQAl6E0AIRAAAKJgALRgMADcYFAAHQAgAPhNACEYSY/l6E0AJghJj+AAEAABEA AAomAQtGAQANxgUAAaAFAA+EoAURhJj+XoSgBWCEmP4ACCAAMZBoAR+w0C8gsOA9IbAIByKw CAcjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAvQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAADAAAA4Mnqefm6zhGM ggCqAEupC0wAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8ASQBE AC0AQwBoAGUAYwBrAGwAaQBzAHQALgBoAHQAbQBsAAAAFQEAAEQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6 zhGMggCqAEupCwIAAAADAAAA4Mnqefm6zhGMggCqAEupC6QAAABoAHQAdABwAHMAOgAvAC8A ZABhAHQAYQB0AHIAYQBjAGsAZQByAC4AaQBlAHQAZgAuAG8AcgBnAC8AcAB1AGIAbABpAGMA LwBwAGkAZAB0AHIAYQBjAGsAZQByAC4AYwBnAGkAPwBjAG8AbQBtAGEAbgBkAD0AdgBpAGUA dwBfAHMAdABhAHQAZQBfAGQAZQBzAGMAJgBpAGQAPQAxADAAMAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQA HAAKAAEAaQAPAAMAAAAAAAAAAABcAABA8f8CAFwADAAGAE4AbwByAG0AYQBsAAAAEQAAAAMk AGEkADEkAUEkACokAQArAEIqAE9KAABRSgAAQ0oYAG1ICQRzSAkEUEoAAF5KAABhShgAX0gB BHRIAQQAQAABQAEAkgFAAAwACQBIAGUAYQBkAGkAbgBnACAAMQAAAAoAAQATpBgBFKQYARIA Q0owADUIAUtIAQBhSjAAXAgBMAACQAEAAgAwAAwACQBIAGUAYQBkAGkAbgBnACAAMgAAAAUA AgAGJAEABgA1CAFcCAFOAANAgQGSAU4ADAAJAEgAZQBhAGQAaQBuAGcAIAAzAAAADAADAEAm AgomAgtGBQAeAE9KAABRSgAAQ0ocADUIAVBKAgBeSgIAYUocAFwIAQAAPAAFQAEAkgE8AAwA CQBIAGUAYQBkAGkAbgBnACAANQAAAAoABQATpBgBFKQYAQ4AQ0oUADUIAWFKFABcCAEAAAAA AAAAADwAQUDy/6EAPAAMABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAA RgBvAG4AdAAAAAAAAAAAAAAAAAAuAP5P8v/xAC4ADAAJAFcAVwA4AE4AdQBtADEAegAwAAAA DABPSgEAUUoBAENKFAAuAP5P8v8BAS4ADAAJAFcAVwA4AE4AdQBtADEAegAxAAAADABPSgMA UUoDAENKFAAuAP5P8v8RAS4ADAAJAFcAVwA4AE4AdQBtADEAegAyAAAADABPSgQAUUoEAENK FAAuAP5P8v8hAS4ADAAJAFcAVwA4AE4AdQBtADIAegAxAAAADABPSgMAUUoDAENKFABCAP5P 8v8xAUIADAAZAEEAYgBzAGEAdAB6AC0AUwB0AGEAbgBkAGEAcgBkAHMAYwBoAHIAaQBmAHQA YQByAHQAAAAAAC4AVUAyAUEBLgAMAAkASAB5AHAAZQByAGwAaQBuAGsAAAAMAEIqAnBoAAD/ AD4qASoA/k8yAVEBKgAMAA0AbABpAG4AawAtAGUAeAB0AGUAcgBuAGEAbAAAAAAAJAD+TzIB YQEkAAwACgBsAGkAbgBrAC0AaAB0AHQAcABzAAAAAAA2AP5P8v9xATYADAAHAEIAdQBsAGwA ZQB0AHMAAAAYAE9KBQBRSgUAQ0oSAFBKBQBeSgUAYUoSAEYA/k8BAJIBRgAMAAcASABlAGEA ZABpAG4AZwAAAA0AGAATpPAAFKR4AAYkAQAYAE9KAgBRSgIAQ0ocAFBKBgBeSgIAYUocACoA QmABAJIBKgAMAAkAQgBvAGQAeQAgAFQAZQB4AHQAAAAGABkAFKR4AAAAOAD+TwEAogE4AAwA DgBTAHQAYQBuAGQAYQByAGQAIAAoAFcAZQBiACkAAAAKABoAE6QYARSkGAEAAFYA/k8BALIB VgAMABEAUAByAGUAZgBvAHIAbQBhAHQAdABlAGQAIABUAGUAeAB0AAAACgAbABOkAAAUpAAA GABPSgMAUUoDAENKFABQSgMAXkoDAGFKFAAAAAAAPBQAAAUAACYAAAYA/////wAAAAAqAAAA WgAAAFsAAACyAAAAswAAALQAAADQAAAAAAEAACUBAAAmAQAAOwEAADwBAACIAQAAMQIAAGYC AAC9AgAAuwMAABgEAABWBAAAAgUAAFsFAAADBwAAEQcAANYHAAB2CAAAIwkAAE4JAADaCQAA XQoAAMsLAAAUDAAATAwAAIQMAAAVDQAAbA0AAJYNAAAWDgAAKA4AAD4OAABPDgAAdQ4AAHYO AAA/EAAAQBAAAFcQAABYEAAAiBAAAIkQAACKEAAAnBAAAJ0QAADREAAA0hAAAPwQAAAGEQAA BxEAADURAAA/EQAATBEAAFkRAABaEQAAvBEAAL0RAAAWEgAAFxIAAIUSAACGEgAA7BIAAO0S AACpEwAAPhQAAAgAAAABMAAAAAAAAACAAAAAgBgAAAACMAAAAAAAAACAAAAAAJgAAAAAMAAA AAAAAACAKgAAAJgAAAAaMAAAAAAAAACAKgAAAJgAAAAaMAAAAAAAAACAKgAAAJgAAAAaMAAA AAAAAACAKgAAAJgAAAAaMAAAAAAAAACAKgAAAJgAAAAaMAAAAAAAAACAKgAAAJgAAAAAMAAA AAAAAACAKgAAAJgAAAAAMAAAAAAAAACAKgAAAJgAAAAAMAAAAAAAAACAKgAAAJgAAAAAMAAA AAAAAACAKgAAAJgAAAAAMAAAAAAAAACAKgAAAJgAASAAMAAAAAAAAACAKgAAAJgAAAAAMAAA AAAAAACAKgAAAJgAASAAMAEAAAAAAACAKgAAAJgAAAAAMAAAAAAAAACAKgAAAJgAASAAMAIA AAAAAACAKgAAAJgAAAAAMAAAAAAAAACAKgAAAJgAASAAMAMAAAAAAACAKgAAAJgAAAAAMAAA AAAAAACAKgAAAJgAASAAMAQAAAAAAACAKgAAAJgAAAAAMAAAAAAAAACAKgAAAJgAASAAMAUA AAAAAACAKgAAAJgAAAAAMAAAAAAAAACAKgAAAJgAASAAMAYAAAAAAACAKgAAAJgAAAAAMAAA AAAAAACAKgAAAJgAASAAMAcAAAAAAACAKgAAAJgAAAAAMAAAAAAAAACAKgAAAJgAASAAMAgA AAAAAACAKgAAAJgAAAAAMAAAAAAAAACAKgAAAJgAAAAAMAAAAAAAAACAKgAAAJgAAiAAMAAA AAAAAACAKgAAAJgAAiAAMAEAAAAAAACAKgAAAJgAASAAMAkAAAAAAACAKgAAAJgAAAAAMAAA AAAAAACAKgAAAJgAASAAMAoAAAAAAACAKgAAAJgBASAAMAAAAAAAAACAAAAAgJgBASAAMAAA AAAAAACAAAAAgJgBASAAMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAA AAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgBASAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgABCAAMAAA AAAAAACAAAAAgJgBBCAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgABCAAMAAA AAAAAACAAAAAgJgBBCAAMAAAAAAAAACAAAAAgJgBBCAAMAAAAAAAAACAAAAAgJgBBCAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgBASAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAyAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAyAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgBASAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgAAEAAA8GAAA DQAAAAAEAADWCwAAdRIAAL0VAAA8GAAADgAAABAAAAARAAAAEgAAAAAEAAA8GAAADwAAAI8J AADDCQAA1gkAAKYMAAAGDQAAEQ0AADwUAAATWBT/FYQTWBT/FYAAAAAAxgAAAM8AAAAAAQAA CgEAAGABAABpAQAAawEAAIYBAACsBQAArwUAAM8IAADYCAAAxAsAAMgLAABSDAAAawwAAIoM AACkDAAAeRAAAH0QAACYEgAAnxIAALMTAAC8EwAAPhQAAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcABAAHABwABwAcAAcAAAAAAFsAAABjAAAAvAAAAMIAAADQAAAA 3QAAADkCAABkAgAAwgIAAAIDAADXCQAA2QkAANoJAAAjCgAAHQsAACELAADjCwAA6QsAAEwM AABRDAAAhAwAAIkMAABDDQAARA0AALkOAADFDgAAWBAAAIcQAAA/EQAASxEAAEwRAABYEQAA NRIAADkSAAAgEwAAKRMAAD4UAAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAEAAcAMwAHADMABwAzAAcAMwAHAP//AgAAAAEAIABCAEMA OgBcAEkARQBUAEYAIAA2ADYAIABNAG8AbgB0AHIAZQBhAGwAXABQAFIATwBUAE8AXwBkAHIA YQBmAHQAXwBpAGUAdABmAF8AZQBuAHUAbQBfAHYAYQBsAGkAZABhAHQAaQBvAG4AXwBlAHAA cABfAEYAaQBuAGEAbAAuAGQAbwBjAAUAAQAAAAEAAAD/D/8P/w//D/8P/w//D/8P/w8AAAIA AAACAAAA/w//D/8P/w//D/8P/w//D/8PAAADAAAAAwAAAP8P/w//D/8P/w//D/8P/w//DwAA BAAAAAQAAAD/D/8P/w//D/8P/w//D/8P/w8AAAUAAAAFAAAA/w//D/8P/w//D/8P/w//D/8P AAABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAACAAAFcYFAAHQAgYCAAAALgABAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAAMCAAAFcYFAAGgBQZPSgMAUUoDAENKFAABAG8AAQAAAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAgAABXGBQABcAgGAgACAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAgAABXGBQABQAsGAgADAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAgAABXGBQABEA4G AgAEAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAgAABXGBQAB4BAGAgAFAC4AAQAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAgAABXGBQABsBMGAgAGAC4AAQAAAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAgAABXGBQABgBYGAgAHAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAgAABXG BQABUBkGAgAIAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQAB0AIGT0oBAFFK AQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQABOAQG T0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXG BQABoAUGT0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA FAgAABXGBQABCAcGT0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAA AAAAAAAAFAgAABXGBQABcAgGT0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAA AAAAAAAAAAAAAAAAFAgAABXGBQAB2AkGT0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQABQAsGT0oBAFFKAQBDShIAXkoFAGFKEgABALfw AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQABqAwGT0oBAFFKAQBDShIAXkoFAGFK EgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQABEA4GT0oBAFFKAQBDShIA XkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQAB0AIGT0oBAFFK AQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQABOAQG T0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXG BQABoAUGT0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA FAgAABXGBQABCAcGT0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAA AAAAAAAAFAgAABXGBQABcAgGT0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAA AAAAAAAAAAAAAAAAFAgAABXGBQAB2AkGT0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQABQAsGT0oBAFFKAQBDShIAXkoFAGFKEgABALfw AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQABqAwGT0oBAFFKAQBDShIAXkoFAGFK EgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQABEA4GT0oBAFFKAQBDShIA XkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQAB0AIGT0oBAFFK AQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQABOAQG T0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXG BQABoAUGT0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA FAgAABXGBQABCAcGT0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAAAAAAAAAA AAAAAAAAFAgAABXGBQABcAgGT0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcAAAAAAAAA AAAAAAAAAAAAAAAAFAgAABXGBQAB2AkGT0oBAFFKAQBDShIAXkoFAGFKEgABALfwAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQABQAsGT0oBAFFKAQBDShIAXkoFAGFKEgABALfw AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQABqAwGT0oBAFFKAQBDShIAXkoFAGFK EgABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAFAgAABXGBQABEA4GT0oBAFFKAQBDShIA XkoFAGFKEgABALfwAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAAAgAABXGBQABAAAGAAABAAAA /wAAAAAAAAAAAAACAAAAAAAAAAAACAAAFcYFAAEAAAYAAAEAAAD/AAAAAAAAAAAAAAIAAAAA AAAAAAAIAAAVxgUAAQAABgAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAAAgAABXGBQABAAAG AAABAAAA/wAAAAAAAAAAAAACAAAAAAAAAAAACAAAFcYFAAEAAAYAAAEAAAD/AAAAAAAAAAAA AAIAAAAAAAAAAAAIAAAVxgUAAQAABgAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAAAgAABXG BQABAAAGAAABAAAA/wAAAAAAAAAAAAACAAAAAAAAAAAACAAAFcYFAAEAAAYAAAEAAAD/AAAA AAAAAAAAAAIAAAAAAAAAAAAIAAAVxgUAAQAABgAABQAAAAEAAAAAAAAAAAAAAAAAAAACAAAA AAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAA AAAAAAAA/////////////////////////////wUAAAAHAFcAVwA4AE4AdQBtADIAAAAAAAAA AAD//wUAAAAAAAAAAAAAAAAA/0ABgAEAfRAAAH0QAABIy0MAAQABAH0QAAAAAAAAbxAAAAAA AAACEAAAAAAAAAA8FAAAUAAACABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAA AAAAAAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAABwAAAEcWkAEAAAICBgMF BAUCAwSHOgAgAAAAAAAAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBt AGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBi AG8AbAAAADMmkAEAAAILBgQCAgICAgSHOgAgAAAAAAAAAAAAAAAA/wEAAAAAAABBAHIAaQBh AGwAAAA/NZABAAACBwMJAgIFAgQEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQwBvAHUAcgBp AGUAcgAgAE4AZQB3AAAAOwaQAQIABQAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAACAAAAA AFcAaQBuAGcAZABpAG4AZwBzAAAAXwSQAQILAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAFMAdABhAHIAUwB5AG0AYgBvAGwAAABBAHIAaQBhAGwAIABVAG4AaQBjAG8AZABl ACAATQBTAAAAXQaQAQASAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgARwAg AE0AaQBuAGMAaABvACAATABpAGcAaAB0ACAASgAAAG0AcwBtAGkAbgBjAGgAbwAAAEIABABB CIgYAADQAgAAaAEAAAAAc8ukRnbLpEYACFEtAwAHAAAA7QIAAK8QAAABAAgAAAAEAIOQIwAA AJ8GAADDJQAAAQATAAAAUAAAAAAAAAAkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMjAAAAAAAAAAAAAAAAAAAH0UAABiLAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWDgAAAAAAAAAAAAAAAAAAAAAA AAAAAgAAAAAAAAAAAAAygxEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ /xIAAAAAAAAAKQBXAEcAIABDAGgAYQBpAHIAIABXAHIAaQB0AGUALQBVAHAAIABmAG8AcgAg AFAAdQBiAGwAaQBjAGEAdABpAG8AbgAgAFIAZQBxAHUAZQBzAHQAAAAAAAAAAQAgAAEAIAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ MAAAAJwBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAADUAAAABAAAAOAAAAAFAAAA7AAAAAYA AAD4AAAABwAAAAQBAAAIAAAAGAEAAAkAAAAkAQAAEgAAADABAAAKAAAATAEAAAsAAABYAQAA DAAAAGQBAAANAAAAcAEAAA4AAAB8AQAADwAAAIQBAAAQAAAAjAEAABMAAACUAQAAAgAAAOQE AAAeAAAAKgAAAFdHIENoYWlyIFdyaXRlLVVwIGZvciBQdWJsaWNhdGlvbiBSZXF1ZXN0AHJk HgAAAAEAAAAARyBDHgAAAAIAAAAgACBDHgAAAAEAAAAAACBDHgAAAAEAAAAAACBDHgAAAAsA AABOb3JtYWwuZG90AGkeAAAAAgAAACAAcm0eAAAAAgAAADMAcm0eAAAAEwAAAE1pY3Jvc29m dCBXb3JkIDkuMABvQAAAAADqVvoAAAAAQAAAAACgyp+DBD4CQAAAAACa8s+QaMYBQAAAAABs PDuRaMYBAwAAAAEAAAADAAAA7QIAAAMAAACvEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3V nC4bEJOXCAArLPmuVAEAABABAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAAB8AAAABgAAAIQA AAARAAAAjAAAABcAAACUAAAACwAAAJwAAAAQAAAApAAAABMAAACsAAAAFgAAALQAAAANAAAA vAAAAAwAAADyAAAAAgAAAOQEAAAeAAAAAgAAACAALwADAAAAIwAAAAMAAAAIAAAAAwAAAH0U AAADAAAAoAoJAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAqAAAA V0cgQ2hhaXIgV3JpdGUtVXAgZm9yIFB1YmxpY2F0aW9uIFJlcXVlc3QADBAAAAIAAAAeAAAA BgAAAFRpdGxlAAMAAAABAAAApAEAAAMAAAAAAAAAIAAAAAEAAAA4AAAAAgAAAEAAAAABAAAA AgAAAAwAAABfUElEX0hMSU5LUwACAAAA5AQAAEEAAABcAQAADAAAAAMAAAACAAEAAwAAAAMA AAADAAAAAAAAAAMAAAAFAAAAHwAAAFIAAABoAHQAdABwAHMAOgAvAC8AZABhAHQAYQB0AHIA YQBjAGsAZQByAC4AaQBlAHQAZgAuAG8AcgBnAC8AcAB1AGIAbABpAGMALwBwAGkAZAB0AHIA YQBjAGsAZQByAC4AYwBnAGkAPwBjAG8AbQBtAGEAbgBkAD0AdgBpAGUAdwBfAHMAdABhAHQA ZQBfAGQAZQBzAGMAJgBpAGQAPQAxADAAMAAAAB8AAAABAAAAAAAAAAMAAABRAFQAAwAAAAAA AAADAAAAAAAAAAMAAAAFAAAAHwAAACYAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQA ZgAuAG8AcgBnAC8ASQBEAC0AQwBoAGUAYwBrAGwAaQBzAHQALgBoAHQAbQBsAAAAHwAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIA AAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAAP7///8VAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAA/v///x0A AAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAA /v///ywAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAD+////NAAAADUAAAA2AAAANwAAADgA AAA5AAAAOgAAAP7////9////PQAAAP7////+/////v////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAA wAAAAAAAAEYAAAAAAAAAAAAAAACwRuA+kWjGAT8AAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAAQ AAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA4AAgABAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAcAAAAjxwAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQYAAAAFAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiJgAAAAAAAAUAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KwAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAzAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQIAAAAHAAAA /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8A YgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAACwRuA+kWjGAbBG 4D6RaMYBAAAAAAAAAAAAAAAAAQAAAP7///////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////8BAP7/AwoAAP// //8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dv cmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA== --------------080907020301070103060008 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------080907020301070103060008-- From enum-bounces@ietf.org Tue Apr 25 15:51:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTY0-0005hg-EP; Tue, 25 Apr 2006 15:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTXu-0005gW-Kl; Tue, 25 Apr 2006 15:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYTXu-00031Q-9B; Tue, 25 Apr 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3PJo1vP030974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Apr 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FYTXt-0006IN-Sj; Tue, 25 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 25 Apr 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-enum-reqs-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : Infrastrucure ENUM Requirements Author(s) : S. Lind, P. Pfautz Filename : draft-ietf-enum-infrastructure-enum-reqs-02.txt Pages : 8 Date : 2006-4-25 This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-reqs-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-infrastructure-enum-reqs-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-infrastructure-enum-reqs-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-25125908.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-infrastructure-enum-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-infrastructure-enum-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-25125908.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Tue Apr 25 22:09:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYZSZ-0005Wd-B7; Tue, 25 Apr 2006 22:08:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYZSY-0005WX-Oq; Tue, 25 Apr 2006 22:08:54 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYZSX-0000Hx-CU; Tue, 25 Apr 2006 22:08:54 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k3Q27DEP017627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Apr 2006 19:07:17 -0700 Message-ID: <444ED5B1.5050105@shockey.us> Date: Tue, 25 Apr 2006 22:06:41 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: iesg-secretary@ietf.org, Cullen Jennings , "Peterson, Jon" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Enum] Request for Publication - draft-ietf-enum-infrastructure-enum-reqs-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a request for publication for one IETF ENUM WG working group document. A two week WG last call on this document concluded on Feb 6, 2006. The document listed below is being proposed for Standards Track RFC. The document incorporates all of comments from the Working Group Last Call. Status- Proposed Standard Title : Infrastructure ENUM Requirements Author(s) : S. Lind, P. Pfautz Filename : draft-ietf-enum-infrastructure-enum-reqs-02.txt Pages : 8 Date : 2006-4-25 This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-reqs-02.txt iesg PROTO DOCUMENT TO FOLLOW. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 26 11:10:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYleT-0007I2-S4; Wed, 26 Apr 2006 11:10:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYleS-0007Hg-JK for enum@ietf.org; Wed, 26 Apr 2006 11:10:00 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYleS-0001N6-4z for enum@ietf.org; Wed, 26 Apr 2006 11:10:00 -0400 Received: from [10.31.13.225] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k3QFARnK018650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Apr 2006 08:10:28 -0700 Message-ID: <444F8D40.8060308@shockey.us> Date: Wed, 26 Apr 2006 11:09:52 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: IETF ENUM WG , Jim Reid , "Lawrence Conroy (Lawrence Conroy)" , Peter Koch Subject: Re: [Enum] ENUM Working Group Last call on ENUM Implementation Experiences References: <442A9BC1.7090606@shockey.us> <20060411182031.GD1162@unknown.office.denic.de> <56EEA54D-0F24-40E4-9730-E6DABF914FA7@rfc1035.com> <20060412131735.GC1892@unknown.office.denic.de> In-Reply-To: <20060412131735.GC1892@unknown.office.denic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Peter Koch wrote: > Jim, > > On Tue, Apr 11, 2006 at 08:40:52PM +0100, Jim Reid wrote: Gentlemen I'm not getting s sense of resolution here. The Experiences 04 draft has gone through last call and if there are revisions required to satisfy consensus we need to resolve those issues ASAP. Peter what do you want the authors to do? The chairs would like to get this draft into the hands of the IESG as soon as possible. > >> First off, even a modest NAPTR RRset will comfortably exceed a 512 >> byte payload. My ENUM zone (3.2.5.2.5.8.8.9.6.1.4.4.e164.arpa) >> contains 6 NAPTR RRs. Which is on the low side for reasonable usage. > > just as a data point, not to argue about the 'reasonable' size: under +49 > the average number of NAPTRs in an RRSet is a little above 2, with very few > going beyond 5 and the largest having 14 NAPTR RRs. > >> etc, etc. This lookup gets a 507 byte response. And that's with >> dropping potentially useful data from the Additional Section as well >> as optimal label compression. With EDNS0, the Additional Section > > Compression is mandatory and there's not much useful in the additional > section in this case, given today's anti-poisoning measures. > >> isn't "truncated" and the full response is 602 bytes. > > No doubt there's a gain (for size, no real one here) with EDNS0 and we are > in violent agreement that EDNS0 is just 'state of the art' (more precisely: > EDNS0 _and_ reasonable buffer size). > >> draft says "All servers involved in ENUM resolution". The client >> doing the lookup or the server resolving that ENUM lookup does not >> have a priori knowledge of the size of the target zone's NAPTR RRset. > > There are servers 'involved in ENUM resolution' that don't even serve NAPTR > RRSets and depending on your setup you might be able to know how large NAPTR > responses will grow. Again agreed, i do not think aiming at 512 is reasonable > in the latter case. > >> Mandating EDNS0 with good buffer sizes is not only essential and >> prudent, it's just an application of the "be liberal in what you >> receive" principle. > > Supporting EDNS0 is just good practice, but the arguments did not support > the claim. Anyway, how can i argue against a non-normative 'MUST'? > >> Even at 6 NAPTRs -- which is by no means XXL sized -- using EDNS0 is > > Sorry for being lazy w.r.t. "XXL" -- i meant that to indicate an RRSet > bringing the response > 512 octets. > >> to get the data that could/should have been in the Additional >> Section. That extra latency is bad news, especially on things like >> GPRS networks. > > Cool, tell that the low TTL advocates. The additional section doesn't > solve the problem, though. > >> We will have to sort this out over a few beers at RIPE52. :-) > > That sounds intersting enough to postpone further detailed discussion :-) > > -Peter > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 26 21:31:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYvLE-0007o0-WF; Wed, 26 Apr 2006 21:30:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYvLD-0007np-DH for enum@ietf.org; Wed, 26 Apr 2006 21:30:47 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYvLB-0005QX-Vs for enum@ietf.org; Wed, 26 Apr 2006 21:30:47 -0400 Received: from [68.165.240.34] (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k3R1V9T3009222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Apr 2006 18:31:12 -0700 Message-ID: <44501EB9.6060703@shockey.us> Date: Wed, 26 Apr 2006 21:30:33 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------020509010603000307000001" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Enum] [Fwd: I-D ACTION:draft-lendl-enum-branch-location-record-00.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------020509010603000307000001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-lendl-enum-branch-location-record-00.txt Date: Wed, 26 Apr 2006 15:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ENUM Branch Location Record Author(s) : O. Lendl Filename : draft-lendl-enum-branch-location-record-00.txt Pages : 6 Date : 2006-4-26 This documents defines the ENUM Branch Location record which is used to indicate where the ENUM tree for special ENUM application is located. The primary application for the EBL is to enable a temporary solution for the infrastructure ENUM tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lendl-enum-branch-location-record-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lendl-enum-branch-location-record-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lendl-enum-branch-location-record-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. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------020509010603000307000001 Content-Type: Message/External-body; name="draft-lendl-enum-branch-location-record-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-lendl-enum-branch-location-record-00.txt" Content-Type: text/plain Content-ID: <2006-4-26120353.I-D@ietf.org> --------------020509010603000307000001 Content-Type: text/plain; name*0="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------020509010603000307000001 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------020509010603000307000001-- From enum-bounces@ietf.org Thu Apr 27 07:20:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ4Xg-00055y-00; Thu, 27 Apr 2006 07:20:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ4Xe-00055t-Nc for enum@ietf.org; Thu, 27 Apr 2006 07:20:14 -0400 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ4Xd-0005z9-CP for enum@ietf.org; Thu, 27 Apr 2006 07:20:14 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 27 Apr 2006 04:20:13 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3RBKCh0000059 for ; Thu, 27 Apr 2006 04:20:12 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 04:20:12 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 04:20:12 -0700 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF ENUM WG From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 27 Apr 2006 14:20:05 +0300 X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 27 Apr 2006 11:20:12.0491 (UTC) FILETIME=[8CF829B0:01C669EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Enum] Issues with 3761 so far X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org [Please don't respond to this email, respond to the original email that describes the ticket, or add issues to the ticket system directly.] What I have in the tracker are the following issues: #838 ORDER/PRIORITY locality ORDER and PRIORITY is significant only within the current domain. This is not clear in RFC 3761. #861 Fast lane for Enumservice IANA registration It is proposed to establish a fast lane for rIANA egistration of non- essential Enumservices using only expert review and not the full RFC cycle. #870 DDDS - RFC3404 reserves ALL flag characters RFC 3404 specifies that all flag characters are reserved "for future versions of this document". #873 Character Set, Case Sensitivity, and NAPTR fields Character Set, Case Sensitivity, and NAPTR fields. NOTE - This is really three inter-related topics. As they are so closely tied together I have requested a single ticket. #874 REGEXP 'i' flag considered harmful RFC 3402 specifies an 'i' flag that can be applied to the REGEXP field. This flag is intended to make AUS matching case insensitive. For ENUM, this is not appropriate, as the allowed characters within an AUS are all case insensitive. #875 Only one Enumservice per NAPTR the syntax for Enumservices given in RFC3761 allows for more then one Enumservice to be given, by addiing them with a '+' #878 experimental ENUM services - clash prevention ecause of the cumbersome process of ENUMservice registration, more and more experimental services are popping up. Contrary to it's intended purpose, more and more of those services are used "de facto" not only internally, but between different parties. This increases the risk of collisions between several different implementations of "experimental" ENUMservices, hence creating the need for preventing collisions between those services. Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 28 03:38:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNY8-0005no-Nt; Fri, 28 Apr 2006 03:38:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNY7-0005ng-F6 for enum@ietf.org; Fri, 28 Apr 2006 03:37:59 -0400 Received: from smartmx-03.inode.at ([213.229.60.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZNY2-0007L9-W4 for enum@ietf.org; Fri, 28 Apr 2006 03:37:59 -0400 Received: from [62.99.233.54] (port=29230 helo=mah9.inode.at) by smartmx-03.inode.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FZNY1-0004MR-HS; Fri, 28 Apr 2006 09:37:53 +0200 Message-Id: <7.0.1.0.2.20060428092715.03e74ea8@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 28 Apr 2006 09:37:48 +0200 To: enum-wg@ripe.net,enum@ietf.org,ga@centr.org From: Michael Haberler Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed; x-avg-checked=avg-ok-1DCB6896 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Enum] +43 Infrastructure ENUM - contract concluded X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org enum.at GmbH, operator of the +43 User ENUM=20 registry, and RTR GmbH, the Austrian=20 regulator,have concluded and signed a contract=20 extension to the +43 ENUM operating contract on=20 April 20, 2006, enabling enum.at GmbH to provide=20 Infrastructure ENUM as currently standardized in=20 the IETF. Service is scheduled to start next month. press releases (in german - english to follow:) http://www.portel.de/news/view_redsys_artikel.asp?id=3D10293 RTR: =D6sterreich baut weltweite Vorreiterrolle bei ENUM aus ... Portel.de - Germany Wien, 27.04.06-11:45 Mit der Vertragserweiterung,=20 die ie enum.at GmbH und RTR-GmbH am 18. April 2006 unterzeichnet haben, ist= ... http://www.ots.at/presseaussendung.php?schluessel=3DOTS_20060427_OTS0163&ch= =3Dtechnologie=20 =D6sterreich baut weltweite Vorreiterrolle bei ENUM aus APA OTS (Pressemitteilung) - Austria Wien (OTS) - "Mit der Vertragserweiterung, die=20 enum.at GmbH und RTR-GmbH am 18. April 2006=20 unterzeichnet haben, ist es in =D6sterreich ... the contract addendum (also german, english=20 translation to follow as well:)=20 http://www.rtr.at/web.nsf/deutsch/Telekommunikation_Nummerierung_ENUM/$file/= ENUM_Vertragsnachtrag.pdf Richard Stastny blog comment:=20 http://voipandenum.blogspot.com/2006/04/infrastructure-enum-in-austria-on-it= s.html Michael Haberler Internet Foundation Austria _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 28 12:32:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVtX-0004zJ-Ep; Fri, 28 Apr 2006 12:32:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVtW-0004zE-Hh for enum@ietf.org; Fri, 28 Apr 2006 12:32:38 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVtV-0004Jf-Aj for enum@ietf.org; Fri, 28 Apr 2006 12:32:38 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 28 Apr 2006 12:31:29 -0400 id 01588061.44524362.000075DC Message-ID: <445243A6.2090707@hxr.us> Date: Fri, 28 Apr 2006 12:32:38 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Tony Rutkowski Subject: Re: [Enum] RE: ENUM Working Group Last call on InfrastructureENUM Requirements References: <32755D354E6B65498C3BD9FD496C7D462C49B0@oefeg-s04.oefeg.loc> <7.0.1.0.2.20060425095824.029b71b8@verisign.com> In-Reply-To: <7.0.1.0.2.20060425095824.029b71b8@verisign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Tony Rutkowski wrote: > Apologies for the U.S.-centric reference. Part 52 of > the FCC's regulations establish the basis for exclusive > authority, administrative mechanisms, and substantive > requirements for the use of E.164 numbers in the U.S. > http://www.access.gpo.gov/nara/cfr/waisidx_05/47cfr52_05.html > > The remark was intended to raise the challenge of devising > any "Infrastructure ENUM Requirements" in an IETF document, > including definitions, when the actual authority to articulate > just about everything in the document resides with national > regulatory authorities. Typically, to produce what is contained > in the document, must be undertaken through a public rule > making or consultative process. Few, if any, have done so. Really!? Can the FCC dictate how E.164 numbers are used in vCard? Can the FCC dictate how E.164 numbers are used on web sites? Can the FCC dictate how E.164 numbers are written on napkins and post-it notes? Somehow I doubt their power is that far reaching. But if it is, I propose we let the rest of the world get on with the business of developing an infrastructure ENUM protocol while the U.S. govt wallows in its own bureaucratic pig sty. -andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 28 16:26:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZX0-000205-WC; Fri, 28 Apr 2006 16:25:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZWz-000200-Sh for enum@ietf.org; Fri, 28 Apr 2006 16:25:37 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FZZWy-0001fN-Ih for enum@ietf.org; Fri, 28 Apr 2006 16:25:37 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 28 Apr 2006 22:29:25 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C49C8@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URN in ENUM Thread-Index: AcZrAnCZwRUai7BESfC2V9GgMvArOw== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Enum] URN in ENUM X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Folks, =20 A simple question: does RFC3761 also allow URNs in the regexp? =20 Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 28 17:08:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZaCF-0001OF-JE; Fri, 28 Apr 2006 17:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZaCE-0001Nv-1P; Fri, 28 Apr 2006 17:08:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZZ8v-0008Q2-9M; Fri, 28 Apr 2006 16:00:45 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZYyX-0005QX-Ms; Fri, 28 Apr 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3SJo1vP004540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FZYyX-0007Vc-BV; Fri, 28 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 28 Apr 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-cnam-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by pine.neustar.com id k3SJo1vP004540 A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Telephone Number Mapping Working Group o= f the IETF. Title : IANA Registration for an Enumservice =D1alling Name Delivery (C= NAM) Information Author(s) : R. Shockey, et al. Filename : draft-ietf-enum-cnam-00.txt Pages : 12 Date : 2006-4-28 =09 This document registers the Enumservice "pstn" and the compound=20 subtypes subtype "cnam" and "data" using the URI scheme 'data:', as=20 per the IANA registration process defined in the ENUM specification,=20 RFC 3761. =20 =20 This data is used to facilitate the transfer of Calling Name Delivery=20 (CNAM) data for calls that originate on the PSTN that may be=20 displayed on VoIP or other Real-time Client User Agents (CUA). =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of th= e message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-cnam-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-cnam-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-28130616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-cnam-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-cnam-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-28130616.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Fri Apr 28 18:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZbaB-0004Ag-Se; Fri, 28 Apr 2006 18:37:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZbaA-0004AW-TJ for enum@ietf.org; Fri, 28 Apr 2006 18:37:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZba9-0002DW-Ky for enum@ietf.org; Fri, 28 Apr 2006 18:37:02 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 28 Apr 2006 15:37:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,165,1144047600"; d="scan'208"; a="26941685:sNHT22312880" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3SMb1TL022797; Fri, 28 Apr 2006 18:37:01 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Apr 2006 18:37:01 -0400 Received: from [161.44.79.144] ([161.44.79.144]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Apr 2006 18:37:00 -0400 Message-ID: <4452990C.5020501@cisco.com> Date: Fri, 28 Apr 2006 18:37:00 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: richard.shockey@neustar.biz Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-cnam-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 22:37:00.0767 (UTC) FILETIME=[43CD16F0:01C66B14] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Just a couple of comments about this: First a small bug: the examples aren't valid according to the syntax of the data url. The syntax requires a comma to preceed the data. And then a suggestion: As defined, you have taken a couple of values out of the namespace of valid names. (I just may want the display name for my business to be "unavailable;cns=u". You can call me weird - it wouldn't be the first time.) The syntax of the data url gives another option. It allows the media type of the data to be specified. The default if none is specified seems to be text/plain, which is fine for real names. (At least in the US. Maybe not for internationalized cnames.) I think you could perhaps just pick some other media type to use to encode your special reserved values. I can't say that I have a particular one in mind, but there are lots to choose from. Paul _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Apr 29 04:03:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZkPl-0006i8-E9; Sat, 29 Apr 2006 04:02:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZkPj-0006i3-Q4 for enum@ietf.org; Sat, 29 Apr 2006 04:02:51 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZkPi-0006Ve-GK for enum@ietf.org; Sat, 29 Apr 2006 04:02:51 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id CB6B81A3DD; Sat, 29 Apr 2006 10:02:44 +0200 (CEST) Date: Sat, 29 Apr 2006 10:02:44 +0200 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] URN in ENUM Message-ID: <20060429080244.GA15759@nic.at> References: <32755D354E6B65498C3BD9FD496C7D462C49C8@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C49C8@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/04/28 22:04, Stastny Richard wrote: > > A simple question: does RFC3761 also allow URNs in the regexp? 3761 says: 2.3. Expected Output The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the 'absoluteURI' production in the Collected ABNF found in RFC2396 [4]. >From RFC2396: 1.2. URI, URL, and URN A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network "location"), rather than identifying the resource by name or by some other attribute(s) of that resource. The term "Uniform Resource Name" (URN) refers to the subset of URI that are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable. ... A URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier. That identifier is drawn from one of a set of defined namespaces, each of which has its own set name structure and assignment procedures. The "urn" scheme has been reserved to establish the requirements for a standardized URN namespace, as defined in "URN Syntax" [RFC2141] and its related specifications. and thus: absoluteURI = scheme ":" ( hier_part | opaque_part ) scheme = alpha *( alpha | digit | "+" | "-" | "." ) So yes: "urn:...." is an absoluteURI and thus allowed in ENUM NAPTRs. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum