IETF-85 Atlanta DISPATCH meeting (Friday, Nov 9th, 2012, 09:00-11:00, Grand Ballroom D). Recording: http://www.ietf.org/audio/ietf85/ietf85-grandballroomd-20121109-0900-am1.mp3 Summary: There were a bunch of people (over 10) willing to work on TERQ. No one was opposed to it moving forward. Plan to refine the charter on list and dispatch it before IETF 86. Notetaker: Dan Burnett ------------------------ - Agenda Bash: hmm, didn't do this -- skipped right past it :) - Chairs gave status update on SIP Forum, SIP Connect IT, SIP NOC, IMTC - draft-peterson-terq-02, "Framework and Data Model for Telephone-Related Queries" Slides: http://tools.ietf.org/agenda/85/slides/slides-85-dispatch-0.pdf Jon presented his slides. There were questions about how subject would be constrained. Are Telephone Number and SPID examples, or the list? Answer: don't want to restrict the set too far today but approximately it needs to remain directory and routing functions. WebRTC is mentioned just to make sure that telephone numbers can be used in the web space. Q: what about multiple identifiers (IMSI and others)? A: Yes, that could probably be added to this set. Q: How accessible is this information? Also, what about delegation? There are a variety of delegated namespaces here. Perhaps go beyond just ENUM as driver. A: All of the data model is abstracted from the protocol, so let's get that right first (and leave it extensible). We can add to charter text if necessary. Q: It's bad to develop model without knowing how it's going to be realized (i.e., transport protocols). SIP O/A is an example. A: SIP O/A works. Q: Are you avoiding choosing protocols, etc. too early to reduce arguments at that level before they're necessary? A: Partially, but mainly there are different ways that people want to implement in different environments, so let's have agreement on the purpose and information before having the beauty contest about the bindings. Q: Before creating a WG we may need to pick a protocol. Otherwise, if we pick wrong, the vendors walk and the work was pointless. A: Yes, so let's not pick early. Why force pick one early? Instead, proposal is to specify requirements first and then create multiple bindings if necessary. (there was some spoken support for the proposal in the room) Q: What are the use cases? You need to first identify use cases before defining requirements. Related to this, you need to know who is asking whom for what info, since the privacy of the endpoints may be more important than the data elements. I need to know the use cases before I even know whether I should join a group. A: Agree that use cases are important. Don't agree that use cases have to come before creating the group. Q: Why will this not fail in the way that ENUM failed? ENUM failed because it is used exclusively behind large walled gardens. A: Disagree that this is a failure. Use in walled gardens doesn't mean it's not useful. Q: How does user information get propagated? How do you ensure proper use? A: There is an authority requirement associated with queries. Q: IETF assumes that everything will be open and free, but that's not necessarily reality. Need to keep in mind that there will be different entities that need to interact according to differing business needs. Query answers needed will vary. A: Agree. Please write this up as a use case :) Q: Would be better to pick only a small number of problems to solve. Don't leave this open-ended. A: Remember that ENUM started with a narrow scope. This is attempting to accommodate the fact that more questions will arise. We will choose a small set of use cases, but some expandability is mandatory. Q: Can we remove "telephone" from the title? This is more about connections that may not even have audio. A: Propose something better :) Several times web ids (e.g., Facebook id) have come up, with a question about whether we need to consider them as well. Jon opined that use cases would clarify this. Q: Are we envisioning public Internet or a more private context? A: more private context, although public Internet usage will not be prohibited of course. Q: Isn't goal here to differentiate access? Goal is not private vs. public. A: You are correct. Conclusions (so far): Security, security model, privacy implications need to be added to charter. Also add use cases as first deliverable. Deadline dates are as useful as they ever are :) Q: Relevance of this work is very date-dependent. If we take too long it will be ignored. Would be best to narrow to only one well-understood use case and binding. Keep it extremely narrow and focused for first target so it gets done quickly. If we go beyond these dates it may be irrelevant. A: Sounds good. Q: Those dates are challenging since there are disagreements about protocol. We must constrain ourselves to approaches that businesses might really adopt. (no real answer) Next steps?? Q: Do we do use cases first, or do we first focus on charter? Cullen proposal: on an email list, request rapid email response on use cases, ask how to address binding issue. If the direction seemed to be okay, then would people be willing to join/work? Basically who would be willing to support this and do work if you could get a bit more info. Roughly 10 hands went up. Q: Can we nail down charter in remaining time? Jon reviews goals of charter. Charter only requires one binding, then recharter. Hadriel's word-smithing includes listing diameter, http. Concerns with "suitable for the web environment". Jon offers to tweak. Q: do we really need to support web environment? A: yes, I'd like one place to get this info, whether getting from phone or web. Q: not possible. These environments are different. A: disagree. Henning believes this is doable. Chair question: anyone opposed to moving forward with this? No objections. Goal then is to get discussion and responses on list so this can actually be formally decided on at next IETF, but we need to make progress on list now or it won't happen.