ENUM WG session Maastricht (IETF78) =================================== Auditorium II, Tue, 2010-07-27 0) Welcome and Administrivia ========================= Session Co-Chairs: Bernie Hoeneisen & Patrik Faltstrom Secretary: Alex Mayrhofer Shepherding Area Director: Gonzalo Camarillo 1) Agenda bashing ============== under AOB Michiel Leenaars will talk about the ENUM deployment in .nl Agenda is accepted. 2) Update on drafts (by Alex Mayrhofer) ================ Peter Koch: Any updates to the document that are of interest to the WG? Alex Mayrhofer answers - some sections to non-normative, concerns about "overriding" 5226 Gonzalo Camarillo (AD) clarifies 3) E2MD Update (by Bernie Hoeneisen) =========== Bernie Hoeneisen explains the basics of the E2MD idea. Use cases GSPID, Service Capability, Calling party name. Q Andrew Allen: Is service capability a wise decision? May not relate to all devices that share a number? Q Jon Peterson: Is there a draft? not yet - Jon mentions that managing real time capabilities could interesting. Bernie Hoeneisen answers that this is a proposal in very early stage and that no I-D has been submitted yet. Bernie Hoeneisen presents summary of feedback received @ IETF-77 Jon Peterson: Thinks that "wide support" is not true - quite the opposite? Talked long before, but didn't see changes in the slides presented. Gonzalo Camarillo (AD): This is not a BoF, we don't need to agree if the last BoF was a success or not Clarification that Bernie presents without ENUM WG chair hat (Q by Peter Koch) Lots of discussion since IETF-77, conf calls, rewrite of proposed charter. Informal Discussion will continue on Thursday after the Plenary. Bernie Hoeneisen says that many discussions at the BoF evolved around that the solution was bad, so more focus on the problem statement rather than the solution. Declared source based responses, source-URI, and large data-sets in the DNS out-of-scope. Q Otmar Lendl: Is source based out-of-scope for now, or for ever? Bernie Hoeneisen: Permanent Hadriel Kaplan: There is a source-URI draft in dnsext - individual draft, actually. 4) E2MD issues (by Bernie Hoeneisen) ============ Bar BoF will be hold in MECCafe at 8pm Thursday. Issue #11 - ENUM NAPTR is insufficient -------------------------------------- NAPTRs perceived wrong - any suggestions for that? Patrik Faltstrom: there are problems with NAPTR, but there are also good things for NAPTRs. Problem is that service indicator is inside the record, not in the query triplet - particularly a problem if you use the owner (domain name) for other services as well. U-NAPTR and S-NAPTR have problems, particularly on top of Unicode (regular expressions and normalization issues). Not saying it's "wrong", but there are couple of issues Jon Peterson: goes back to tpc.int - hierarchical structure was always been a bit of a mismatch (area codes are not hierarchical in NANP), for relational things DNS is unusable, RegExp has always been weird because virtually all apps do a full replace, further replacement field is not being used. A lot of NAPTR fields are actually not being used. Too many buttons lead to interoperability issues. For mapping just phone numbers to URI, one could build something much simpler. Peter Koch: Are we going back to the "FUD" (Architectural issues), and arguing that everybody who's against E2MD is against ENUM? Bernie Hoeneisen clarifies what will be discussed. Peter Koch: NAPTR is strictly defined only in the DDDS context. This was changed with RFC 3761. In hindsight DDDS is probably not the optimal choice. By separating the E2MD Use Cases there would be an opportunity to revisit this choice (learning opportunities). It would have applied to ENUM if we had the knowledge back then. Gonzalo Camarillo (AD): Clarifications of issues is great, discussion whether it's FUD or not is irrelevant. Lawrence Conroy: NAPTRs have their problems, yes. RFC 3671 improved NAPTR specification significantly, so that human beings could actually use NAPTRs. We have a few million domains, probably private, but it works. Beauty of ENUM is that normalization (RegExps) is not a problem, because we're only using digits in ENUM. We can use RegExps with DDDS in ENUM. But if you try to move it outside the ENUM case, there a lots of sharks circling. Hadriel Kaplan: Is there an IAB document, or not? Patrik Faltstrom: Yes, there is. it is the "how to extend DNS" document, now an RFC. It is not specific to NAPTR. It talks about the selector being out of the query triplet. If it would have existed back then, ENUM would probably have been done differently, but it might still be the case that DDDS would have been the choice. Remember that the revision of RFC 3761 was first proposed as using a different RR (URI RR), but it was rejected by the WG, among other issues missing support for RegExp had been mentioned to be a problem. Alex Mayrhofer: Liked it a lot, but was too late and it did work with wildcards :-/ Issue #6: DNS Basis ------------------- Jon Peterson: A lot of discussions we had such as Hadriel's source routing draft illustrate why the DNS doesn't work for ENUM as it currently is and why the DNS needs to be changed. Things like phone number routing go beyond the capabilities of the DNS. A lot of what has come up in E2MD are kind of symptoms of fundamental disconnect. Back then, when ENUM was imagined to be a "directory", the DNS worked pretty well. The more we walk away from that the less DNS is the perfect protocol. Infrastructural aspects, soft-switches, more compound and complex queries are what's exposed the fundamental misalignment between DNS and the requirements for telephone number routing. Peter Koch: Confirms that complexity and new requirements coming from so-called infrastructure ENUM are the part that is hurting here. Notes that there are regulatory issues (L9 stuff) when using e164.arpa for something else than ENUM. Lawrence Conroy clarifies that e164.arpa is not our business, it is the IAB's and ITU's business. Below e164.arpa it's a nation state issue. Is not clear that there are any AUP requirements for domains within e.g. 9.4.e164.arpa. and does not believe there are any for 4.4.e164.arpa. E2MD is just different data for E.164 numbers, would refuse to put dial-plans or something into e164.arpa. Peter Koch: Is it a reuse, or are we taking about private namespaces? Bernie Hoeneisen: E2MD is mainly targeted for private and infrastructure ENUM deployments, but some use cases might also be used in e164.arpa (Public User ENUM), but this is not the main focus. Patrik Faltstrom mentions that RFC 3245, the history and context of telephone number mapping (ENUM) operational decisions, Informational, contribution to ITU-T SG 2, March 2002, contains what we agreed on at that time. Lawrence Conroy: RFC 3245 is referenced ion 3761bis. Dave Crocker: Need to fragment the term ENUM into different terms, because you mean different things. Understood Jon Peterson's comment as if you take something and you try to use it for more that it was designed for, it might not work well. And in this case ENUM was designed for certain kind of use, and if you try to apply it to complex queries and other things that it wasn't designed for, it won't work very well. I don't find that very surprising, the part that is surprising is that anyone would expect it to and try to call it the same thing. People need to be very clear about different scenarios and there really are different services. It would probably help to use different names for these things. My understanding what E2MD is for is that it is to take a particular style of ENUM use and associate some attributes to certain points along the name tree. There are indications of particular uses for that, and then there is the question of what the technical details for doing that are. Can't imagine that basic questions about whether ENUM is a good thing are relevant to that exercise. Confused to see that showing up in this and would certainly hope that those very important discussions are taken away from this very narrow topic. Alex compares DNS with HTTP. A very successful protocol seems to be "bent" for new applications and requirements it wasn't initially designed for. DNS is everywhere, you get it through firewalls. Seems that DNS would be bent much more than HTTP. Maybe should look how HTTP folks have been dealing with such new requirements. Or maybe looking into which part of the DNS might be useful for something else. Back to the terminology issue: ENUM is actually e164.arpa. Bernard Aboba: Many of the slides don't really help clarifying what the specific objections are. There are very specific issues which relate to the use of the DNS for things the DNS can't do well. It's not trying to redo ENUM. It specifically relates to E2MD and not something else. A lot of comments did not say it can't be done in the DNS they were just criticizing the way in which the proposal set to do them. As an example you can put URIs into DNS, you don't have to put the objects themselves into DNS. You can put pointers to DNS. Hadriel Kaplan: Agrees with Dave Crocker: Terminology is an issue. Also "DNS" is more - we're using the "DNS protocol" - isn't E2MD aimed at broader than just private use? Bernie Hoeneisen: E2MD is targeted to instantiations of ENUM Technology in private and infrastructure environments. And yes, there is a terminology issue. Hadriel Kaplan: ENUM Technology is used successfully outside the Internet DNS, not in Public DNS. Bernie Hoeneisen: There are some use cases that can be also used in public infrastructure ENUM, but don't make sense in public user ENUM (e164.arpa), e.g. send-n. Each use case is different and each can be used (or not be used) in certain variants of ENUM technology. Otmar Lendl: Structure is a good choice for public ENUM, maybe less for infrastructure, for example "guaranteed response times". Jon Peterson: There are other protocols that have hierarchical structures. E.164 numbers are not hierarchical in practice, lots queries are done with flat labels due to number portability. Dave Crocker: DNS has zones. Zones can collect together part of the hierarchy. So that in fact DNS queries can be in the extreme a flat query, if you choose to configure things that way. The fact that the [E.164] numbers are hierarchical and the fact that you can choose to configure in extreme hierarchy doesn't mean you have to. So there are some differences between the theoretical design and the practical implementations that are available. Does not understand the relation of these things to E2MD. Jon Peterson: Isn't that the *ENUM* WG? Gonzalo Camarillo (AD) clarifies: Idea is not to change ENUM at this point - but we want to discuss issues in the E2MD context. Patrik Faltstrom clarifies from a co-chair point of view: Hard to distinguish issues between ENUM and E2MD. Supporting this discussion as we are close a decision whether to close the ENUM WG (declare victory and go home) or whether to start the work on another bis-bis document. Hadriel Kaplan: E2MD is basically extension that are relying on ENUM. Thought that feedback we got at the BoF were great area of just saying "ENUM is broken". But things work, but the prove of evidence is not sufficient to the IETF. In the NANP the hierarchy is not clean, but that only a problem of public ENUM. In the private context it doesn't matter. We keep using the word ENUM for different flavors. Jon Peterson: Too many DNS hierarchy labels is the least of all of these issues. We should not focus on that. It is a bad much, don't disagree with it, it can work. Lawrence Conroy: In closed private context ENUM has been bent a lot (deep pre-caching, etc.), and it even works for such things. But such things don't fit the model of the DNS. Does not want to see them in public. There are very special requirements. But it does work. Why it works, is another matter. Otmar Lendl: If you continue to add all the features like guaranteed response times or source dependent queries, at some time DNS will break. Hadriel Kaplan: Question whether it is an opportunity to re-factor the protocol or whether to keep adding on top of the protocol. Successful protocols are those that have incremental additions as opposed to those that have a complete re-boot. That is the state we are in. Alex Mayrhofer: Successful protocols tend to be bent, but need to consider bending the protocol beyond what it can do. Maybe just look at certain parts of the DNS protocol suite, and use those for a potential new protocol (e.g. transport, caching). Hadriel Kaplan: It's proven that it works. It is not about transport, not about firewalls. Question: Is only the source-URI overloading the protocol or also parts of E2MD? Alex Mayrhofer: Source-URI is just a good example, but pretty sure other stuff will follow and at some point it is going to break. Issue #10: Size of DNS answers ------------------------------ Jon: there are two sides - query labels as well as resource records that you require from it. Sure that we break tons of implementations by being to large. Agrees that this is not a problem for the things we have been talking about in E2MD. Otmar: If we can get the selector into the query, we might be able to squeeze down the response size. Probably not a problem even with current NAPTR setup, but not suitable for long term. Peter: There is difference between "length of RR" and "length of RR-set". How many different services you are going to use in the same RR-set is a question of scale. We need to be careful while designing this. Danny Mc Pherson: Large record sizes can be used for reflective amplification attacks, and can cause operational problems. Issues #14 Cases Not specific to DNS: ------------------------------------- Jon Peterson: "send-n" and "unused" are kind of predictive. This kind of predictive things have a much more general applicability than just E.164 numbers. Whether they are advisable is a different question. Encoding them in NAPTRs seems weired. Peter Koch: "send-n" and "unused", both try to influence the DNS resolution a "layer up". It doesn't fit the model. It holds no matter whether it is called for ENUM and E2MD or anything. Lawrence Conroy: Very early drafts of "void" (before it changed to "unused") was intended to avoid wildcards. Was a DNS hack, though an elegant one. However, it got removed from "unused" and has not been in "unused" for the last five year. Thus, the problem has gone away for "unused". Ray Bellis (as answer to Jon's comments about predictions): "send-n" and "unused" are definitely assertions; no predictions involved. Jon Peterson clarifies what he meant with predictions. Ray Bellis: "send-n" optimizes the amount of SIP queries leading to "404 Number Incomplete" and saves several additional round trips in SIP. Lawrence Conroy: "unused" is only about the number (or rather zone in which this is) that you have looked up, in which case it says give up with this number. It doesn't say give up with another number. Jon Peterson raises synchronization issues between PSTN and ENUM. Lawrence Conroy: ENUM is always a predication. If it's a contact in ENUM, it is a prediction: if you use this SIP URI, you are gonna get a session. That is a predication. Jon Peterson: Difference is that a contact URI is used to contact something, where "unused" says stop and don't try to do something. Prediction has always a certain amount of this uncertainty to it. Peter Koch: "unused" is like the MX RR: If no MX RR, look for A RR - unfortunately - and then for AAAA RR, which was a repetition of the mistake. It makes it very hard to find out whether the service is not available. This is exactly the information, which people want to convey with the "unused service". Lawrence Conroy: "unused" gives you a session to whatever announcement you wanna play to. Doesn't care whether it is E2MD or ENUM. Issue #5 Commonality among services ----------------------------------- Jon Peterson: "why is all the info in one bucket" - what are trust and security relations among several records? Putting them all under a single rubric of metadata seamed like they just not have enough in common to justify that. Problem of service selection is mentioned. Bernie Hoeneisen: Even in ENUM we have so many services that have not much in common: some are for number portability, some are for finding communication parameter, some are for business card. Issue #9 Security/Privacy ------------------------- ENUM had a security & privacy milestone - what happens with that one? Gonzalo Camarillo: ENUM charter will be updated anyways after the Trilogy has been approved. Bernie Hoeneisen: Security and Privacy issues are common to ENUM and E2MD. AOB: Deployment in .nl ====================== Michiel Leenaars talks about ENUM deployment in the Netherlands. In case of the Netherlands, ENUM is about social media - so e.g. twitter account to the phone number, built an application called "ENUM discoverer" (http://enumdiscoverer.nl/) available for Android phones (like Motorola Droid); it looks up information in the DNS, while dialing the number with a smart phone. Think that business case for user ENUM is in this domain. Application goes to phone-book every 10 minutes, and "fills up" the phone-book Hadriel Kaplan: Which tree? Michiel Leenaars: Public User ENUM tree [e164.arpa]. Otmar Lendl: Aware that this can be easily crawled? Make sure that users know this. Richard Barnes: .tel did lots of privacy - looked at that as well? Lawrence Conroy: Privacy is something that's really required.