IETF 67 - minutes of the ENUM working group =========================================== 06.11.2006 - Grande Ballroom A, Sheraton Harbour Island San Diego, California, USA agenda bashing ============== http://www3.ietf.org/proceedings/06nov/agenda/enum.txt agenda is being accepted without comments. draft review. ============= http://www3.ietf.org/proceedings/06nov/slides/enum-0/sld1.htm - no new RFCs since Montreal - 2 in RFC editor queue (enum validation arch, PSTN data) for ENUM - additionally, ENUM dip indicator by IPTEL in RFC Editor queue. - bunch of docs in publication process mentioning the void draft: ========================== (no presentation) http://tools.ietf.org/html/draft-ietf-enum-void AD have requested the WG to re-review this doc. shockey thinks personally that this may be useful, esp. in private ENUM scenarious. Question by ADs posed: a) appropriate use of ENUM infrastructure b) addresses tis doc the problem correctly? shockey requests comments on void: 1) should we continue moving that forward? 2) any issues making it more valueable regards number allocation vs. number in service? most people interested would use that in private ENUM. jon peterson: doc has been around in stuck state. there are very fundamentalquestions regarding the methodology of the doc (DNS assumptions, eg). q posed to the chairs: is there going to be an update, and enough energy in the WG to investigate those serious questions? peter koch: have put up a comment about "inappropriate use" of the DNS. question should be addressed. Is really concerned about those assumptions about DNS. stasty: two opinions problem: "inappropriate use" vs. "useful information". is useful information especially when there are only few numbers in ENUM. shockey: what are the alternatives to this? need an ENUM query which returns the status of a certain number... what is the correct methodology ???: analogy: would you like to have the info that a domain name is challenged in the DNS? This is admin data. do you have that in the DNS? Data about admin status of a domain name in the DNS itself? alex: we have that data in the DNS. "locked" in TXT records... peter: we don't have that in there. might be an unstandardized way then. but: paradigm: query is not the problem - response is. zone boundaries have to be transparent - this is not the case here, because information is being interpreted. Thinks that this is a dangerous way to follow. jon: we'll not gonna solve that here. Has the group the will to do this? strong opinions indicate interest. 2nd point: Enumservices guideline could be the doc to hold information on how to make assumptions. could have lessons learned from that draft in there. stastny: fed up with that other people say that this is useless... jon: it's up to resolve the "discuss" positions - is the WG willing to do? sinnreich: short comment: DNS is not a replacement for SS7. shockey asks the room about how many people think the "unallocated" / "unassigned" issue is a problem that we actually have? relatively small number.. how many think that the ENUM WG wanna solve that problem here? Seeing sufficient people .... How many are willing to contribute? see sufficient people raising hand that they will be interested. email Richard Stastny, and work on another revision before Prague. closing void. Experiences draft ================= (no presentation) http://tools.ietf.org/html/draft-ietf-enum-experiences Any more comments, or can we take that to WG last call? shockey asks for comments. no comments - issues resolved? Moving forward to last call? peter koch: confused - assumed that to be a living document which would not be last called? shockey: not my impression... peter koch: ok. EDNS0 dealt in other document.. shockey: right. peter: but, even though aiming at informational, it makes clarification of 3761... and in some points probably clash with that even. this was to be a living document, wasn't it? shockey: would be logical to bring that issues back to the list? paf: problem that we'd like some docs to be drafts forever, and'll never finish them. have the impression at least when talking to people in the hallway.. 3761bis + URI [audio 33:30] ===================== (no presentation) http://tools.ietf.org/html/draft-ietf-enum-3761bis http://tools.ietf.org/html/draft-ietf-enum-uri paf speaks about those drafts (as an author, not as chair): paf found the emails about the issues. conclusions seem to be: people runing certain services (eg. telcos) want the DNS for those records, and they want a delegation for that. don't accept delegation "back" from user, or other telco. want to have a "proper" delegation chain. correct? (agreement) So, next question: How to implement this? User-ENUM violates that requirement because telco cannot control the zone... using the URI record delegation model would mean that user cannot control the zone (the requirement from user ENUM). Nervous about breaking out a ENUM tree for a _specific_ service (telephony). could then happen again for SIP, email, fax, .... so tecnically, there might very well be more than just one tree, hence. penn pfautz: view on "seperate trees": numbers are allocated to service providers, and assigned to users. penn: user has right to the number as a user. penn: service provider has "another" right to the number as provider. penn: so, is there an issue there? there are only two rights on a number... understand the problem technically, but might be not practical... patrik: mixing user rights and service provider rights - user has the full right on porting is number, but cannot influence portability database itself. also mixing up E.164 number's role as identifier for generic communications service with the function as identifier for a specific service, namely telephony. so what are the implications of an email service to eg. the telephoney service? henry: portability makes the user "own" the number. henry: can do telephony even without an number. service definition by an old addressing mechanism? patrik: we're here to use E.164 as input - that's the very purpose of the ENUM group ... output is whatever URI... penn: want to make clear: E.164 numbers as allocated are not ONLY for telephone? penn: nobody talks about making user@provider portable... penn: structure of phone numbers: they are not allocated based on a specific service. one can use any service with the number... penn: so, see no contradiction between the user doing whatever he wants, and (2) the telco doing whatever he wants with the same number sinnreich: phone numbers are tied to narrowband telephony. otmar lendl: one main reason: different delegation points for single numbers and allocated blocks. so mixing those delegation borders makes trouble. shockey: no need to reargue the infrastructure reqs here... patrik: case that we have not been talking enough? otmar: URI draft now as well, or later? patrik: let the questions conclude, then URI draft? otmar: what about the rfc3761bis doc now since it violates basic reqs? patrik: would like to do another round of document - one example is flawed. klaus nieminen: comment on first question regarding different services: we have single operators in the traditional world for a number, but this operator then puts the number in where it's neccessary. klaus: there is user right to have the user domain delegated, but this is fine with user-enum. jon: would like to see detailed change log on that doc. otmar: URI draft: URI record does not work with open numbering plan. because number cannot be "put back" into the URI.. patrik: do you dial the full number, or is it two stage? otmar: two ways: direct dialling, or overlap dialling. penn: the whole number needs to be sent. a record for any full number would need to be populated. unforseeable numbers of records. patrik: ok, users can "add digits" to the number... otmar: routing prefix based, they don't care about the digits "behind" the prefix. [16:46:59] just like subaddressing was in X.25 ... otmar: carrier does not even know the length behind a customers number. [16:47:32] worse than wildcard: non-terminal 8-( patrik: URI draft should therefore just specify the URI record itself, and not talk about delegation stuff, is that what you say? delegation stuff would then go into rfc3761bis. otmar: simple regex in it would be useful. shockey: any other q on URI draft? ???: If only about the URI RR, why is that in ENUM? patrik: next q, please? :-) softswitch requirements draft [56:30] --------------------------------------- http://www3.ietf.org/proceedings/06nov/slides/enum-2/sld1.htm http://tools.ietf.org/html/draft-lim-kim-enum-based-softswitch NIDA operates +82 ENUM zone since 2005. two Korean VoIP SPs are now testing routing using ENUM. ENUM modules have been embedded on their softswitches according to RFC3761 enum in +82 currently contains numbers of 2 carriers only. provisioning is done using EPP. (shows a classical ENUM call routing slide) so, in the beginning, not all numbers are in ENUM. so, question: what to do when a switch cannot get routing info from ENUM? so, to have the softswitch route all calls, not just those for which enum is available. simple method: softswitch MUST lookup ENUM info. if info exists - use it. if no info, uses it's own routing database as fallback. (falls back to "legacy routing") (slides with examples). first example with URI returned from ENUM -> use this. second example: no ENUM info, use lookup table to find destination. jason livingood: what is the objective of the ID? Is this an informational, what's the overall goal. shockey: isn't the scenario obvious? penn: would agree that this looks obvious, but at least one implementation does not confirm to that. shockey: struggles with this draft, because too obvious. jean francois mule: doc defines what happens when RCODE 3. but: there could be other methods a softswitch does - we might want to keep this open... jason: understand where this comes from. shockey: don't think that this is WG item at this stage - what problem are we trying to solve? authentication scheme draft [67:50] ----------------------------------- http://www3.ietf.org/proceedings/06nov/slides/enum-5.ppt http://tools.ietf.org/html/draft-chenh-enum-app-auth provides a mechanism to authenticate the user. client a encrypts, client b receives message client b contacts authentication center, receives key. if encryption is wrong, the call fails. jon: this is a SIP security thing shockey: this is DKIM for ENUM. alex: (BTW, we had a similar draft in Dallas from me, actually). jon: what is the security property that we're trying to achieve? jon: this is probably the wrong place to discuss SIP security, it has been studied extensively in SIP. jonathon rosenberg: ENUM is only for phone numbers. so this doesn't work with an SIP URI. shockey: ENUM is probably not the right place to discuss security authentication related stuff. jon: pops up in a lot of places, lack of DNSsec is limiting Keys in DNS. jon: OTOH, DNSsec itself is putting keys in the DNS - could be reused for applications jon: DKIM is controversial, similar issues in SIP. jon: DNSsec probably the best way to generalize such stuff... shockey: *looks at charter* seems not to be in.. there exist more appropriated places. ??: seems that this draft is not soo much tied to SIP, and rather tied to ENUM.... shockey: is a security / authentication issue, not a ENUM issue. patrik agrees that it does not fit in scope. dave crocker: again, this is not too much tied to SIP, more to DNS. dave: DNS already has security issues that we live with. dave: the fact that data retrieved is keys is more a nuisance rather than a problem? Q: if DNSsec would be deployed in ENUM, would this exist? jon: yes, it would - this is about application keys. Xiaodong: This is not just for a certain application. it is more a framework, based on ENUM. comment: sounds like circular logic. shockey: patrik identified scope problems. WG has not expertise to judge this work. Enumservice for XMPP [85:00] ============================ http://www3.ietf.org/proceedings/06nov/slides/enum-1/sld1.htm http://tools.ietf.org/html/draft-mayrhofer-enum-xmpp Alex Mayrhofer presents xmpp enumservice draft-mayrhofer-enum-xmpp-00.txt XMPP is standardized: rfc3920f used for: IM, Presence, VoIP (google-talk). Lots of clients available [17:19:43] don't forget dingaling! ;) RFC4622 defines the xmpp URI scheme this is a simple service type definition considerations specific to XMPP: No auth component. i18n allowed for now alex requesting adoption as WG item. jon: sounds like a plan. shockey requesting hum, WG adopts document as WG item. paf wants people who use XMPP to really look at this. ENUM branch location record [93:30] ----------------------------------- http://www3.ietf.org/proceedings/06nov/slides/enum-4/sld1.htm http://tools.ietf.org/html/draft-ietf-enum-branch-location-record offspring of the "Dallas treaty" supports the "interim" solution to Infrastructure ENUM. approach store the position where the Infrastructure ENUM tree branches off. has 4 parameters "application" "seperator" "position" "apex" also supports the "final" solution, transition possible. there are implementations for OpenSER (CVS, patch for 1.1 required) And there is an implementation for Asterisk. open issues: application: use a registry? use underscore prefix? Terminology: Define the "infrastructure" label already? in the document itself? Location: where do we store the EBL record? cc Level? or Other options? eg. "have it always at position 4"? Austria (+43) is running an I-Enum-Trial now branch hardcoded to "i.3.4.e164.arpa" need the EBL to get other trials up requesting input from DNS people. Draft could be stripped down to the basic RR type, and don't define the ENUM application in that draft - would make the RR definition uncontroversial. olaf kolkman: please strip to RR definition. also wait for 2929bis. getting a new RR allocation will then be a matter of filling out a form. olaf: however, not sure how fast 2929bis will be out.. shockey moves to floor mike: reiterates that he does not like the draft. otmar: have noticed that already. stastny: thought that we've sorted that out already. stastny: linked to "combined" , so should be a WG item. shockey: it is already [17:38:08] Rich - in Dallas you agreed to support the combined ENUM effort in good faith, signed the contract - now please stick to it! ENUM services guide ------------------- http://www3.ietf.org/proceedings/06nov/slides/enum-3.pdf http://tools.ietf.org/html/draft-ietf-enum-enumservices-guide bernie presents. skips editorial draft. security considerations: should we have that in each registration, or point to it, other options? jon: should be one thing that we can reference. stick it in this draft, break it out later. jon: notices that it would be a downref if it's just a BCP. jon: could also be in 3761bis. subtype mandatory? "no" suggested. seperate registrations for each subtype? "yes" suggested. no comments so far. URI scheme always matches subtype? "no" suggested. Seperate registrations for sep. URI schemes? no suggested. What track are we aiming for? jon: BCP would match the doc type. jon: do we need to normatively reference this doc from Enumservice registrations. jon: if the doc does not specify how ENUM itself works, it probably does not need to be referenced normatively. should it update RFC3761bis? "no" suggested. peter koch: administrative stuff should be discussed elsewehre. add text about experimental service? yes suggested. add text about extending existing ENUM services? finally: what is the IANA impact? jon: there are a lot confusing things about ENUM services. jon: there would be guidance appreciated about how to define Enumservices. shockey: do you want to solve the "void" problem in this doc? jon: not talking about "void" here, but would like to capture the experience of the last Enumservices (lot of Enumservices proposing http...) Enumservice IAX =============== (no presentation) http://tools.ietf.org/html/draft-ietf-enum-iax Ed guy talks about IAX Enumservice. IAX itself is going into expert review in the next few weeks. meeting concludes.