IETF 68 ENUM minutes ==================== Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alexander Mayrhofer RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson jon.peterson@neustar.biz MONDAY, March 19, 2007 1300-1500 Afternoon Session I enum Congress III Telephone Number Mapping WG session material: ----------------- Agenda: http://www3.ietf.org/proceedings/07mar/agenda/enum.txt Presentations: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 Jabber logs: http://www3.ietf.org/meetings/ietf-logs/enum/2007-03-19.html Audio recordings: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/ietf68-ch3-mon-noon.mp3 (ENUM session starting at [76:00] into the file, times of individual topics are listed below) Agenda bashing [76:31] ====================== no objections Document review [77:00] ======================= Slide deck: http://www3.ietf.org/proceedings/07mar/slides/enum-3/sld1.htm - 2 RFCs since ietf 67 (4769 ENUM-pstn, 4725 ENUM validation arch) - 1 related item (ENUM dip indicator) - bunch in the publication queue (calendar, caller name, infrastructure- combined, branch location record, infrastructure, enum xmpp) - edns0 in AD evaluation - enum validation token in AD eval - enum validation epp in expert review - very close to IESG eval: enum instant messaging, intrastructure reqs - in IESG eval: vCard & void shockey: good progress, cleared up queue pretty well jon: clean division between enumservice and "other stuff". need the guidelines document done to be "done", because must work without WG as well. shockey: two items top on list: revision of 3761, move to draft standard, and enumservice guidelines - then pretty much done. review of 3761 [81:25] ====================== no slides. patrik faltstrom speaks: made one version of 3761bis before last IETF. will release a new version after IETF 68. no comments on this. ENUMservices guide [83:00] ========================== slides: http://www3.ietf.org/proceedings/07mar/slides/enum-1.pdf Bernie Hoeneisen speaks. changes since last time: implemented IETF67 (no objections to proposals). new section about DNS considerations (credits Peter Koch) new stuff in security considerations seciont (from vCard draft) still open issues: Experimental Enumservices (possibly make another draft, bernie will make a seperate draft) no feedback on the experimental enumservices draft so far. lawrence likes the experimental draft. noone thinks this is a bad idea. no comments about "changes of existing enumservices". jon peterson: does not want to see that this doc has no IANA considerations, because it has. If ENUM WG to be closed, then we need guidelines for expert review here, would be appropriate here. could be in another doc as well. ??: not only put criteria, but also templates for that review. offers help on that topic. lawrence conroy: experimental is not the same as rfc3761 registration. might need a different doc for those "experimentals". what kind of docs are appropriate for that? Jon says we should have an discussion on that. lawrence: full blown standards track might not suit for experimental. Jim reid: need lightweight process. needs process to aquire and to indicate how codepoints are used. Jon: could be slippery slope. not sure how an "experimental" could then be differentiated from "real" service (migration, pre-registration?) Lawrence: wants crystal clear difference between experimental and productive. does not want a single registry. "something that is out there" vs. "is a service brought through IETF process". Bernie: experimental is supposed to have less registration hurdles ??: look at URI schemes ("transitional" vs. "permanent"). not sure how services could be distinguished on the wire. shockey: yes, for experimental the simpler the better. Enumguide is for sure a standards track document. peter koch: other examples of IANA guidelines are BCPs. because purely administrative matter. shockey: any objection to going forward as BCP? moving forward as BCP. bernie: need to align with 3761bis, and haven't done yet a "WG independent" method of Enumservice registrations. shockey: would appreciate to have that ready by Chicago. last discussion should happen there. the sooner the better. experiences draft [98:50] ========================= slides: http://www3.ietf.org/proceedings/07mar/slides/enum-4/sld1.htm Lawrence Conroy speaks. hasn't changed much - actually lost a section (important things from DNS section moved to EDNS0) tried to tag each issue (STD, etc...) - found things in the wild labeled as advise (ADV)... please read and provide comments. shockey: doc going for ~2 years. prepared to last call? lawrence: think we are ready, but wants feedback first. got rid of contentious dns stuff. patrik: would like to have various suggestions numbered so that they can be referenced. void/unused [103:40] ==================== slides: http://www3.ietf.org/proceedings/07mar/slides/enum-5/sld1.htm Lawrence Conroy speaks. "unused" is replacing "void". Jon: is not said anywhere in the doc... Lawrence: said in the cover note (was not passed on) 2 parts, basic enumservice definition and provisioning text enumservice gives a hint to "give up now", not proceed to the PSTN. (don't use "default fallback") - needed for ENUM-only ranges, because PSTN falls back to ENUM again. not _restricting_ to ENUM only number ranges, though. provisioning issue: how do you provision "non-registered" numbers? currently wildcards, but Lawrence dislikes them. bad idea in many different ways. tried to find alternatives to wildcards, section 7. could remove it from document, which means the doc will be shorter. Peter Koch: agrees with the points about wildcards, but this is "synthesizing" wildcards on the client side, which might be worse (zone boundaries are only administrative...) - deriving info from zone boundary seems to be a bad idea. Patrik: looked into "how bad is it when clients start searching" - some DoS like scenarious from broken clients... nervous about _specification_ of such searches. standardization of the enumservice could be delayed because of those considerations. Lawrence: alternative from that or wildcards? Jim: issue about finding closest encloser - seems to be a clear solution. which of the two "alternatives" do we want Leslie: sounds more like a DDDS application itself? get out of DNS entirely, like return information to go to a different DDDS application... Lawrence: thought about it a lot - lots of thing don't change, so not sure that leaving _that_ DDDS makes sense Leslie: can talk offline. Jon: document around for long - holding only "DISCUSS" which is a blanket for a lot of other DISCUSSES... message seems to be that people don't know how to do that with _DNS_... speaks for leslie's point. Lawrence: perfectly possible with DNS - called wildcard. but... Peter Koch: understands what this is about - problem where this comes from is that ENUM provides a "fallback", and now we need a "oh, don't fallback". Similar situations in other WGs where info is put into the DNS, problem is reappearing. that info was stuffed into the answer for a completely different reason (letting the cache know the SOA, and expiration time). Jim: agrees that soa is there for neg caching... so differentiate between "data" and "information"... overloading the purpose here. Lawrence: maybe split it into 2 drafts: Enumservice draft, "closest encloser" draft (chopping out section 7 into another doc). Patrik: could _mention_ the issues in the Enumservice draft, but keep the talk in the provisionin issue. no objection against splitting the docs - way to go. E.212 Enumservice [126:50] ========================== slides: http://www3.ietf.org/proceedings/07mar/slides/enum-0/sld1.htm Ed Lewis speaks: two items: Enumservice for E.212, and tel-URI-Parameter rough drafts. E.212 is an ITU recommendation about information in mobile networks: MCC (mobile country code), MNC (mobile network code), MSIN (subscriber identification number) together forms IMSI docs are about ENUM - want to put E.212 info into ENUM. E212 enumservice refers to a tel: URI. use case is to location information about an operator for a mobile number. Jonathan Rosenberg: is that info public? Ed: defining that for private/infra ENUM use. Stastny: E.212 is not tied to a phone number, so tel-parameter makes no sense Ed: wants only the MCC MNC info, not the MSIN. Stastny: second issue: why an ENUMservice? simply put it in the tel URI itself. tel-uri draft: in the style of the number portability tel URI parameters. defined all 4 parameters for the tel URI, but will only use 2 on the ENUMservice didn't want to restrict syntax to much in terms of combination of parameters this to iptel? lendl: information is public in Austria (can determine network for ported numbers) Jon: iptel only if iptel survives... focus on the enumservice here. had a history on attaching markup data to URIs - cnam, number portability. Jonathan Rosenberg: concerned about taking every piece of data into the tel URI parameter, just because we want to have it in ENUM. warning sign for wrong tool? Stastny: info not suitable for a tel-URI, because distinct from a phone number.. Lawrence: even in other URIs (data) need to define structure... rohan mahy: maybe a UUID formed from E.212 info? Jon Peterson: agrees with the architectural issue of "data stuffing". Guidelines for decision of cases like this needed - guidelines doc? hum indicates that this is valuable enumservice - second issue (how to express data) is to be taken to mailing list. Jon: maybe an IMSI URN? ??: Already had a draft for a URN space - maybe will do a followup under GSMA space. ENUM softswitch requirements [157:50] ===================================== slides: http://www3.ietf.org/proceedings/07mar/slides/enum-2/sld1.htm JoonHyung Lim speaking. followup to San Diego meeting. is an advisory document. ENUM is not providing a guidance how softswitches should act based on ENUM entries (or their absence) defining call routing process for certain scenarios. Experience from Korean trial. found that no significant delay in call routing due to ENUM queries. Otmar Lendl: routing based of RCODE "no data" = failed call? sensible? better fall back to the PSTN? Lawrence: likes the draft. Interesting choice about "dropping, or go to the PSTN"? shockey: WG issue: want that as WG item informational? hum indicates this is now official WG document. please contirbute. Open mike time ("shoot the chairs") [166:30] ============================================ jon peterson: this is about the status of infrastructure documents. "memos" etc. sent out are "emails", and cannot alter concensus of the WG. but they reflect questions, esp about the charter deliverables (which says we gonna provide infrastructure ENUM). also about liasions, and how to manage e164.arpa. Has no specific answer on those issues - but WG should come to a conclusion what they want, and bring the documents forward. Are those concensus of the WG? Shockey: they certainly reflect concensus. Jon: will then bring those forward as the will of the ENUM WG to the IESG. Shockey: has personal no objection to them going forward. opinion in memorandum was personal. lots of backchannel discussions in recent days, and much closer to a concensus now. agreed to use the list to provide guidance to IAB/IESG about what opinion of the group is. Jon Klensin: "one place to look" was the argument to allow e164.arpa. infrastructure goes into the space of ITU - involves national matter of defining carrier definition. if ENUM WG wants to shoot ENUM into the other foot, this is the way to do it. Jim Reid: got impression that IETF is running, and saying "we don't want to know". IETF _does_ do Internet Standards, so Infrastructure ENUM is naturally to be done in the IETF (or at least, Study Group 2 will look at the IETF). Jon: memorandums etc. had no effect on the processing of the documents. Wimmreuter: ITU is waiting for instructions - right way to avoid the complicated process we originally had - but they are waiting for us. get drafts to RFCs, and tell the ITU to go ahead with whatever apex they want. Jon Klensin: SG2 did everything to kill off e164.arpa already (new TLDs, etc.), then they decided to make it experimental. now we say "take it out of the user's hands, put it into the carrier's hands" - doesn't think this is the right way. Jim Reid: SG2 has been working on a recommendation on User ENUM (going for 6 years already). thinks a liasion how far IETF is going, and where ITU is starting to do the work may be useful (drawing the line). Lawrence: not neccessarily "carriers" to decide, but countries. about the "one place": user's mapping very distinct from service provider's mapping. will ever be only two trees (end users / carriers). "Who has admin control" is the question, too. Haberler: reason for two trees: e164.arpa semantics have failed to live up to the expectations. conclusion of the WG was that two trees are the most sound solution from tech point of view. Hoeneisen: Taking up Willi's point: Ask ITU to proceed, but leave actual apex open? Daryl: Might work in certain countries, but is highly unlikely that CC1 will use it - they will continue to use their most complex systems already in place. Doesn't think adoption is realistic. Lawrence: Even if we leave the apex open, we should at least _recomment_ one. Rohan: agrees that what we do here has few to do with actual politics. If we get a few countries to get using our technology, it's still worth doing. Thinks that closing ENUM WG and opening a new WG for infrastructure ENUM would be sensible. Willi Wimmreuter: IETF is the "protocol engine" - let others decide whether/how they use it. Haberler: appreciates that "global" != "east coast to west coast". Some countries are more open to interopability. Jim Reid: Disagrees that noone ever will implement it - some countries are looking at using infrastructure ENUM for number portability. In US, ENUM tech is used in that area, too. Patrik: had very useful discussion over the last few days - review of the documents will of course continue in the IESG/IAB. Shockey: sure that IESG/IAB will have more questions as the docs come up - list still open. We did our job - now in the realm of IESG/IAB. Jon Peterson: Sure that they will need feedback from the group. Meeting concludes [194:20]