IETF 68 SPEERMINT Minutes ========================= Session PEERing for Multimedia INTerconnect (speermint) Tuesday, March 20, 2007, 0900 - 1130 (Morning Session I) Room Name: Congress I ======================================================== CHAIRS: David Meyer Jason Livingood SECRETARY: Alexander Mayrhofer RAI AREA DIRECTORS: Cullen Jennings Jon Peterson RAI AREA ADVISOR: Jon Peterson session material ---------------- Agenda: http://www3.ietf.org/proceedings/07mar/agenda/speermint.txt Presentations: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 Jabber logs: http://www3.ietf.org/meetings/ietf-logs/speermint/2007-03-20.html Audio recordings: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/ietf68-ch1-tue-am.mp3 (SPEERMINT session starting at [02:00] into the file, times of individual topics are listed below) Administrivia ------------- Jason Livingood is sick, and can't be here. Session was shifted because of certain "priorities" - Dave's daughter getting married. Agenda bashing [03:30] ---------------------- Dave explains Agenda - no objections/additions Review of Milestones and Document Flows [04:30] ----------------------------------------------- General idea of SPEERMINT was to get use cases to anchor whole things. Didn't get them early on, so decided to change document flow. Document flow now based on what we learned. After terminology: Will first have use cases, then requirements emerging from there, and then going to architecture. Will first focus on VoIP. After general architecture going to detailed architecture. (message flows, dns uses, etc..) Picture shows now VoIP and IM, but could be generalized to any service. ??: Would be nice to add presence Key point: we don't want to admit any new work items without a corresponding use case. milestones: Dave will be able to work on the terminology draft when he leaves IAB in about 3 days. then enhanced VoIP/IM use case, and then detailed protocol details. then step back and look whether to recharter, or close down, etc.. brian rosen: seems reasonable. seems to be the best guess we can get. rohan mahy: looks perfectly fine to me. lawrence conroy: message flows could take a while - they usually have bugs in them. will submit updated charter and milestones after meeting. Terminology draft [12:40] ------------------------- Dave has a huge directory of comments on those drafts, but hasn't done anything with them yet. Promises to put work into that, after that IETF. Real time collaboration (IM & PResence) use cases [14:40] --------------------------------------------------------- Slides: http://www3.ietf.org/proceedings/07mar/slides/speermint-1/sld1.htm Proxy for Avshalom speaking. Concentrates on use cases for presence and IM Believes that domains will need IM and presence interworking. several use cases (user to user, user to resource list, authorization, exploding presence information on the other end, etc.) IM use cases (page mode, session mode, would be a media function via MSRP relays) Rohan Mahy: would "handing just one doc over" work with selective presence? Answer: This is just a use case doc at the moment. Jonathan Rosenberg: yes, would work. has to. more use cases: application sharing, file transfer. do we want to see more use cases, or are we happy to move over to requirements q from jabber: distirbuted chatrooms? answer: no. chatroom is in one domain. jonathan rosenberg: concerned ab out splitting up use cases: file transfer is for me just another media type... how are we scoping media types? answer: currently seperated between "voice" and "everything else". cullen jennings (individual): have no standardized work for "application sharing" in the IETF - remove that? Jon Peterson: for the purpose of collecting use cases, may be valid to keep that. how that goes into requirements is a different story. if you have other use cases, please contribute. other requirements: nat/fw traversal? discovery of services in domains? overload control? federation of domains (direct peering as well as clearing houses). mapping of presence docs between domains. jonathan: what is currently not in the presence doc that requires gateway functions? what is the use case for two SIMPLE compliant domains? answer: we are looking at any cloud wanting to federate, not just SIMPLE. DND does not map very well. jonathan: don't want to see an "excuse" for more "custom" PDIF attributes (no "presence" SBCs!) answer: action item taken to explain that mapping in more detail. will feed back what we found out into SIMPLE. other use cases: consolidation of data flow. alex: we have already interopability: XMPP / SIMPLE.. jonathan: i don't understand seperation between "voice" and "real time collab". ??: don't forget to mention that IM may use different path.. alex: maybe the difference is between "replacement of classical telephony" and "everything else". Adam Uzelac: big discussion whether to collapse or not. decided to keep them sepearate, but there are lots of arguments to collapse them. Jonathan: fine to seperate them by technical differences, but not by "marketing" terms. steve norris: why does presence have more privacy sensitivity? answer: because might eg. contain location.. brian: that is not correct. doesn't want to see that in the draft. Dave: Q where we are with that draft? seems we need another revision.. VoIP consolidated use cases [34:45] ----------------------------------- slides: http://www3.ietf.org/proceedings/07mar/slides/speermint-0/sld1.htm Adam Uzelac speaking. renew the focus on use cases from there gather unique requirements all four use cases tried to capture the same bits of information create a common terminology between use cases, and align with terminology draft. capture nuances between use cases (enterprise/carrier/direct/indirect) 3 categories: indirect, direct, assisted. all cases fell in one of the buckets direct: typical bilateral agreement, two VoIP providers without something in between. indirect: trust relationship between originating domain and 3rd party, as well as a trust relationship between 3rd party and terminating domain. david schwartz: "indirect" is that on the business level, you are peers, but for some reason there is something in between, while "assisted" is with a central function, to which both are peers. federations: groups of SPs agreeing to receive calls. jon peterson: distinction between federations and other constructs? otmar: direct/indirect/assisted is about the message flow / technical stuff. federations is more on the administrative level. jon: forming a distinction between technical and administrative level, and do we want to have that there? rohan: not sure everyone got the distinctions.. take the pics from the draft up on the screen? brian: document structuring issue: anything different between VoIP and "IM" yet? jon: at the use cases stage, we decided to collect into two buckets. had rough concensus that VoIP is more critical in the first place than other things - hence two buckets. not neccessarily to change the doc structure at this point. reason for splitting was that "everything else" might get VoIP delayed. david schwartz: indirect,direct,assisted are building blocks while federation can use any of them. daryl: example would help to find out whether drafts overlap. lot of terminology in there. adam: all use case drafts had slightly different terminology, so creating common terminology has to be achieved. lot of that should go to terminology draft in the end of course. second, this is a "draft" in the most literal way. Jon: are federation use cases? or on some higher layer? adam: struggled in organizing the doc, yes. david schwartz: suggest to take out trust and business models out of direct, indirect,assisted. Otmar: agrees with jon - federation is about finding peering partners. different question from finding the actual path. Jon: seems to be a good point to go forward - however, federation is _one_ model of doing administrative trust. please avoid talking that federation is the only admin model. Otmar: example of two peers is the most simplest federation. Jon: term has different meaning in community. "federation" means a pre-existing agreement. Dave: terminology draft needs to reflect those things as well. some nits found - new version shortly after that meeting. will document some nuances as well. Jonathan: want to have that draft a bit longer - would be a place to keep requirements for enterprises. different authorization process, etc. more dynamic points of interconnect - different scale (very large number of enterprises connecting to fewer large carriers) elwell: happy to maintain it - doesn't want to push that as a final deliverable. Adam: had a conf call, some things are pretty different, although technically, the intereconnection between two enterprises is not much different from carrier interconnect. differences are around security nuances, trust nuances, not around technical things. ??: should be folded in the consolidated VoIP draft, and not kept around as a WG doc etc... Keith: there are carriers out there who still think enterprises are simple terminals, so we need to built this in. francois: agrees that that might be pretty similar, but we _might_ need a seperate document (discussion premature?). Keep it in the same bucket now, and take it apart when it becomes necessary? elwell: keep my draft as some kind of reference? to make sure it doesn't fall on the floor, and everything we captured is being taken care of in the final deliverables? jean-francois: keep both docs aligned (carrier/enterprise) - but maybe a bit early to decide that we should merge... enterprise people are different from carrier people in terms of that they look at. milestone is in 2008, so we have some time - let ECMA etc. contribute. don't close the doors too early. steve norris: relationship between carriers and enterprises is different - what is an "enterprise"? whole gamut of services... DSL-line or "Ford"? elwell: yes, likely to address the larger enterprises. true that IETF can't influence business relations, but the technical tools need to be there. otmar: enterprise-carrier "peering" is tricky. seperate use cases not between "carrier" and "enterprises", but on "technical" differences. Adam: disagrees with jean-francois. draft has been vary valueable to drive differences into the consolidated use cases. keith: need to make sure the enterprise peering use cases shows up in any documents we make. rohan: we don't need to make a distinction unless there's a difference on the wire. thinks that provisioning might be one of those things. Dave: seems as if we don't have concensus to merge or keep them seperate. Drafts need to be structurally aligned - people talk anyway. Peering considerations for directory Services [91:00] ----------------------------------------------------- slides: http://www3.ietf.org/proceedings/07mar/slides/speermint-3/sld1.htm John Haluska speaking This is about directory assistance - peering for services, not for terminating calls. wants to show the different use case, and would appreciate feedback on it. trying to get IETF comments on whether this is "kosher" - trying to get more power out from using SIP. service routing logic could be based on a lot of different things - caller identity, agreements. different languages, etc. connection between home provider and information services provider could be treated of a peering. Rohan: address service via request uri? a: yes, could be possible in that scenario. rohan: recommendation from the SIP community that services are to be addressed via the request URI. a: is definitely one of the ways we're doing it. interaction between a, b, c (redirect, etc.) is like indirect peering. may be the case when service is reselled. Adam Roach: Adding intermediary doesn't make that much different - RFC3087 says how to do that. semantically doing something different is a bit odd. Adam uzelac: yes, speermint does cover some of those use cases. just setting up voice, eg. is clearly covered. Dean: 2 mechanisms: retargetting vs. re-routing. used retargetting in most cases, but sometimes re-routing might be the preferred mechanism. brian: doesn't see yet a connection between this and what SPEERMINT does. Dave: summarizing: John looks whether there is a use case we don't cover. (end of agenda) Unstructured discussion [114:00] -------------------------------- david: provisioning issue? breaking it off or not? thinks that requirements are understood. is very complicated, causes real problems today, is not on the SPEERMINT roadmap. Feedback? Cullen? Jon? Jon: did receive a peppermint BoF proposal, did not accept it. Impression was that documents etc were not mature enough to have a BoF. Would probably be mature enough by the next IETF. is not a denial of the problem, though. Provisioning dicussion somehow derailed discussion in SPEERMINT, so that might be an argument for it. doesn't like the documents to be in SPEERMINT, though. high level: yes, seems to be a plausible thing, probably for chicago. shockey: mailing list will be open - will probably try to get a non-BoF BoF. Provisioning is extremely important, will need to look at the minimum subset first - not boil the ocean first. Will re-propose BoF in Chicago. Jon: yes, agree - rejection is not a done deal. meeting concludes [120:00]