IETF 65 (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 Real Time Applications Infrastructure Area Advisor: Cullen Jennings fluffy@cisco.com ????? 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-00.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.txt 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.