Minutes for E2MD BoF at IETF 77 ------------------------------- based on notes by John Elwell, Jabber session scribed by Patrik Fältström edited by Bernie Höneisen, Dean Willis Meeting started approximately 10 minute late due to delay in room exit by prior group and equipment problems. Both chair's personal computers kernel-panicked on connecting to the projector, and an attendees' machine was pressed into service. Subsequently, the cord fell out of the main microphone. Chairs verbally reviewed "Note Well" and agenda, but did not present related slides due to equipment delay. Chair declared that the question for today's meeting was whether we should form a working group to solve the problems that will be discussed today using the general approach of a new DDDS based on ENUM. Chair noted prior guidance from the IESG is that such a specification would need to be written as if it were to be used on the public Internet, even though use in private networks is more common. AD Cullen Jennings declared that this was not necessarily the case, and the group should first decide what it wants to do. John Klensin suggested that if the work result is not intended for the public Internet then it should be renamed, because a name like E2MD implies a parallel to ENUM, which really was intended for the public Internet during its conceptualization phase. The chairs stated that the basic idea is similar to ENUM, but instead of mapping the E.164 number to a URI that identifies the resource labeled by the E.164 number, we are mapping the E.164 number to information about that phone number. Jon Peterson noted that there had been some discussion on the nature of the URI in ENUM, and that it identifies a resource but is not necessarily used for establishing a session with that resource. Topic: Problem Statement and Use Cases led by Bernie Hoeneisen Slides presented reviewed several use cases under discussion: * "unused" use case introduced by Bernie * "send-n" use case introduced by Ray Bellis * "cnam" use case introduced by Richard Shockey * "Global Service Provider Identifier" use case introduced by Bernie Noted that the ENUM working group agreed a draft on the CNAM use case, and that the DRINKS working group earlier this week had discussed mechanisms for provisioning a global service provider identifier. Jon Peterson asked: What is metadata? These 3 use cases are all rather different - is there really anything in common? Debate ensued, with the one commonality noted that all the data in question has in common that it is keyed by the E.164 number and might be needed either when starting or accepting a session using that E.164 number as its target or source. Bernie noted that ENUM had different kinds and classes of ENUM services, and had provided a classification mechanism as part of the IANA registration document. Ray Bellis responded, discussing the relationships between the send-n and unused cases with ENUM. Both send-n and unused are helpful in resolving ENUM lookups and need to be done in conjunction with the ENUM lookup, literally at the same time. John Klensin challenged the assumption that the DNS is a good place to keep this data, noting that we have a lot of other information that might be keyed by the phone number but that we do not store in the DNS. Further, storing data in the DNS with record types that lead to a potential for contradictions or unclear semantics gives a potential for abuse of the DNS. We will need to be able to say why each piece of metadata is important enough to put it into the DNS, Bernie noted that the DNS is a good way of distributing the responsibility, and that the delegation structures and relationships of the metadata in question are identical to those of ENUM. Dean reported that John's question had already been discussed on the mailing list, and the sense of mailing list was that we already have the phone number keyed structure from ENUM and we need the same hierarchical and caching characteristics, so any new protocol would need 90% functionality of DNS making it not worth inventing something new. Peter Koch noted that CNAM is rather different from the other use cases. For send-n, he doesn't believe that the problems with the proposal are removed by using E2MD rather than ENUM -- that it makes no difference what the string in NAPTR is. He suggested that killing the whole dependency on ENUM stuff and doing a roll-over not based on NAPTR may be a better approach. Olaf Kolkman agreed that the ENUM tree matches well with hierarchy, but wondered what form of query/search systems might be needed. For example, if we need to search for metadata with a specific number, it might be better to have a service just for that. He suggested that it might be good idea to look for different tools for this problems. (Note: Olaf followed up with email to the list that this perhaps was too strong of a statement and there are some problems, e.g. with +1 and the unknown delegation points in certain number plans.) Dean noted that this had come up in on-list discussion, and that the later discussion would touch on using E2MD to find a URI for a metadata service. Dean noted that the existing use cases had been debated on the list and that the list felt that DNS was a good match for these use cases, but that we would need to provide guidance on evaluating future use cases as. John Klensin noted that when we did the ENUM work, we mapped phone numbers to DNS for a a specific reason, but assumption that numbers were well matched to DNS would be wrong. The inverse ordering model creates a vast number of DNS hierarchy levels and is not particularly optimal. Richard Shockey responded that ENUM does work well, and is deployed in a number of trees. Practical experience shows that it would work equally well for other types of data. Jon Peterson noted that ENUM kept running into security properties, and the constraints in E2MD may prove to be even more restrictive. Richard Shockey noted that there are many successful ENUM deployments in private environments, and that this resolves most of the security issues. Andrew Sullivan suggested that the problem is that there is a tiny part of DNS that is not a good fit, but if that is an important part, then we should reconsider using DNS as the basis for E2MD. Topic: Issues from List led by Dean Willis Issue: DNS record size. List discussion agrees that the E2MD space in DNS is size constrained, and that each use case will have to be analyzed for suitability and unsuitable use cases rejected. further, the group agrees that they will have to produce guidance documents for future reviewers of use cases. Cullen challenged the group to scope this so it would be approvable, apparently asking for the review guidelines to be finalized before the work is done. He proposed a use case of putting a ring-tone into the DNS, and asked how we would evaluate it. Discussion ensued, with some participants maintaining that this is a valid use case, others suggesting that this was a bad idea and that it would perhaps be reasonable to insert a URI that indicates a ring tone. Lawrence Conroy noted (via remote) that an upper bound on size is probably 250 bytes. Issue: Is everything a NAPTR? Jon Peterson observed that this goes beyond just CNAM not being like the others. Why should we use NAPTR, if we have to do some kludge on the data just to make it fit into a NAPTR record Patrik Fältström noted that there had been a number of problems with NAPTR record with ENUM, so perhaps we shouldn't use it for this, in the same way we should not have for ENUM. Need to see what record types match and perhaps use a better choice, rather than just following ENUM. Jon noted that it is improbable that one RR type would fit all use cases, and that we would therefore have to look at each use case separately. This suggests that we do not need an overall framework for metadata, but should charter work for individual metadata use cases. Discussion moved onto response filtering and aggregation. Spencer suggested that having a profusion of resource record types might be even scarier than everything being one NAPTR or one container. Dean noted that multiple RR types might be one approach, and that various other filtering techniques might be applied. For example, the underscore prefixing used with SRV records might give a clue to another possibility. Question: How large are the responses. Dean responded that with many use cases feeding into a NAPTR RR-set we might have very large responses. Dave Crocker observed that our current discussion is about low level implementation choices. We need to or might do lots of different things, but without very specific use cases as goals, we have no way to select an approach. He also berated the group for not having considered underscore prefixes as used in SRV records. Dean noted that we do have 4 specific use cases under discussion, with I-Ds on 3. Bernie stated that about 10 more have been proposed to the list. Jon asked what these use cases have in common? Dean responded that the information is indexed by the phone number and used when either setting up or answering a call, to which Jon disagreed without further explanation being recorded. David Schwartz noted that the common factor is not "has to do with call routing", since the CNAM proposal clearly doesn't. Issue: Registration Procedure Current document suggests Specification Required (with Expert Review procedures TBD). Cullen supposed that if ENUM were 1st come 1st served, we would not be having this BoF (we would have just done it in ENUM, with the implication that this would have been a Bad Thing). Richard Shockey noted that the proposed process follows ENUM as closely as possible, as the ENUM process has been shown to work. Conclusion: Polls of the Room Poll: Who thinks there is something worth looking it? A lot of people raised hands. Poll: Who thinks DNS is a suitable basis? Dave Crocker declared that since we don't have specific set of problems there is no rationale for deciding whether DNS is the right basis. Chair responded by moving to discussion of specific use cases. Poll: Who agrees DNS is suitable for CNAM: 10 for, 3 against. Poll: (asked by Richard) We are debating solutions before we establish a charter.Is this a problem that we in IETF can solve, are there people who would like to fix problems? Response was mixed. Christer asked that if we assumes SIP is the main usage, can we solve CNAM with SIP OPTIONS? Dean responded that it is doable with a SIP event package, and that this approach had been previously suggested. Gonzalo suggested following up with questions from the "How to have a successful BOF" list such as "should a WG with the following charter be formed?" Poll: Who thinks the problem space has been clarified by the current drafts and proposed charter such that we understand the proposed scope? Mixed response. Poll: Are there people who want to solve problem: a fairly large number. Poll: Who has read the proposed charter? A large percentage responded. Poll: Who thinks the proposed charter is close to being usable? Response generally favored the negative. (Note: This was a close thing, with the responses being somewhat clustered in the room. Some observers reported an even split). Poll: Who thinks the proposed charter is too vague or proposes an untenable approach? Response generally disagreed that the charter was adequate. Gonzalo observed that we didn't really discuss the charter in this room, and we should have asked the question whether we want to propose a WG based on that charter. The chairs, who thought they had just asked that question, merely nodded in response. John Klensin suggested that we should ask who thinks proposed charter it not ready to go. The chair responded that the question had already been asked, and that more people thought it was not ready to go than thought it was ready to go. Chair's conclusion: The problem scope appears to be clearly defined, but the general solution model of defining an open-ended framework is problematic due to concerns about review and approval, and concerns about the general applicability of the ENUM process to encompass the larger metadata problem. Consequently, the proposed charter defines too large a scope. An approach that scales back to solving specific metadata issues one at a time may be more sustainable. Alternately, a solution that strongly revises (or replaces) ENUM might be better tolerated by the community.