IETF70 SPEERMINT WG session =========================== Session PEERing for Multimedia INTerconnect (speermint) Monday, December 3, 2007, 1300 - 1500 (Afternoon Session I) Room Name: Salon A/B =================================================================================== CHAIRS: David Meyer Jason Livingood SECRETARY: Alexander Mayrhofer RAI AREA DIRECTORS: Cullen Jennings Jon Peterson RAI AREA ADVISOR: Jon Peterson Meeting Agenda: http://www3.ietf.org/proceedings/07dec/agenda/speermint.txt Audio recordings: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf70/ietf70-ch5-mon-noon-speermint.mp3 (meeting starts at 19:00 into the recording) Jason Livingood opens meeting Welcome slides: http://www3.ietf.org/proceedings/07dec/slides/speermint-1/sld1.htm All presentations are on the meeting materials site. flowchart slide: shows document order milestones slide - hopefully WGLC on terminology after this meeting IM usecases draft is DONE. Voip usecases on the agenda - hoping to go to WGLC soon other drafts put back because of terminology draft (commitments in jan / feb 2008, those commitments might be delayed by a few months) humble requests: please read drafts before WGLC! no feedback for authors is frustrating - the earlier the better When providing feedback: "no dead birds", please - provide solutions for problems that you identify, an suggest text. agenda bashing [23:50] ====================== final feedback on VoIP use cases final feedback on terminology detailed discussions on requirements and architecture unfortunately jean-francois is still in the air, and cannot attend/present :-/ Afterwards open discussion - in particular about security issues. Yui - VoIP Use cases [25:00] ============================ Draft: http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-04.txt Slides: http://www3.ietf.org/proceedings/07dec/slides/speermint-2/sld1.htm hopefully the last presentation before wg last call. tried to align terms with terminology draft, and clean them up. tried dividing use cases in static and "on-demand". each of them subdivided into "direct" and "indirect". asking for objection from the group. no objection against those categories... Daryl Malas: Terminology: "session border element" eg. duplicate. yui: we _will_ remove that, not done yet. (will be in -05) yiu: the categories above (direct/indirect) are then subdivided into "assisted" and "not assisted" Richard barnes: please clarify "static" and "on-demand", "direct", "indirect". "direct" sending to target itself "indirect" via some transit provider "assisted" means someone helping to find the target domain. ??: difficulty to find out what's going on here: 03 has different categories Yui: we failed to publish 04 in time, it came out this morning in new draft, added admin characteristics and options for each of the categories. david schwartz: doc getting a lot better. still sense a lot of confusion between "assisted" and "indirect" in all three docs. daryl: about the "session manager" idea - that was confusing in the 03 draft. was originally defines as a registrar, and it originally looked as if such an element was out of scope, because it's beyond the border element. yui: something inside the domain has to help us with routing and registration. suggest we rename it? daryl: confusing what is eg. doing the lookup function. we should seperate proxy from registrar. how are we exactly defining session management? proxy and registrar? yui: yes, both. can of course be split in two boxes. daryl: one box, mutliple things is ok. david: logical, not physical entites: lookup / border element. lots of confusion between logical and physical functions in the documents - keep logical and p. registrar does not fit within the "domain to domain" peering. registrar is for local users, and is not in scope of SPEERMINT. A provider's own stuff should not be in scope of SPEERMINT. daryl: "user endpoints" defined. does it help the use cases? if yes, i'm fine with it. Jason: such things fine for illustrative purposes. Jason: suggest that yui/daryl get together and resolve that today offline. Jason: document timeline: now 04, soon to have 05 with comments from now. Any open things that need answers from the group? Daryl: Federation. in the voip use case it's a "simple" federation, while in the terminology it seems more than two. Jason: can we say "two or more"? Sohel: SM can also connect to application on the other side. (??) David schwartz: look at definition of "lookup function" or "location function". it's defined differently in terminology and use cases. 4.1 and 4,2 please unify terminology, and type of data returned. (lookup vs. location) yui: we can remove the definition, and it becomes "location function". David: Make it inline with the terminology draft. other major question: When we seperate use cases, is this the right approach? static / on demand. each of them "direct" / "indirect" and then "assisted"/"not assiseted" ??: direct/assisted not completely clear. transit model seems not be defined very clearly. yui: i don't have direct L5 connection to the target so i need transit - that is defined as indirect. David: want to find some time to clear this up before end of the week terminology draft (Daryl) [47:20] ================================= draft: http://tools.ietf.org/id/draft-ietf-speermint-terminology-13.txt slides: ?? revision 14 is not out yet, got a few more comments back, v14 going out soon. some definitions are still there in use cases (for example, in the VoIP use case, we still have "transit" -> indirect). reference to a "SPP" signaling peering point - we need to complete terminology, please don't define more terms. At some time, the terminology draft must be finished.. John elwell: agreeing, different terms in different docs, some alignment in recent weeks. if there are "re-definitions", are they really needed? daryl: terminology document shoud be the "standard" for our other drafts. want to finish that really quick. if you have a term that you need, define it in the use case (or other) drafts, but not delay terminology anymore. We can't keep that document John: is the group comfortable with what we have? Daryl asking whether the group is missing terms. No one speaks up. James Mceachern: Any new terms should be defined in any draft they're using it, unless it is in the terminology draft. Jason: make a term section in the individual draft if needed. Daryl: just to be clear session manager is a proxy . Adam Uzelac wants terminology finished now. John: Are we comfortable with the "SED" definition? SIP URI is the beginning of the SPEERMINT process, might come from ENUM or from any other source. Richard Shockey: need to cut this off real soon. Agreeing with Adam. Dave: how many people would object starting WGLC? none. Will WGLC this. James Mceachern: SED data confusion need to be resolved. David: suggest that its "the data that provides info on how to reach the next hop". Jason: concensus that when 14 comes out we will WGLC. any other drafts are pointing to this document, and if they define their own terminology, they should have a dedicated section for this. David: suggests a whole draft dedicated on SED. Requirements draft [60:00] ========================== draft: http://tools.ietf.org/id/draft-ietf-speermint-requirements-03.txt slides: http://www3.ietf.org/proceedings/07dec/slides/speermint-0.pdf Jean-Francois delayed, still in a plane. Jason provides basic information about the doc. Jean-Francois was waiting for the terminology draft to complete, as well as for the VoIP use cases. changes 03: status for doc was changed to informational, scope on enabling the use cases defined. open issues: otmar wants more clarity between indirect vs. assisted - touches on terminology. Daryl: yes, is addressed in terminology, thinks this is done. John Elwell: we need to hv advertisement of ingress points (eg. rfc3263 is a way of advertising). Jason: please take the time to check whether he addressed your comments. otmar comment from jabber - "glad that this reflects requirements for speermint, and not requirements on SIP providers wanting to p. Daryl: confusion again about "SPP" session peering point (3.2) - this doesn't seem to be in terminology draft. Jason: Please take some time to close that out - main concern is the "SPP" term. Architecture (Reinaldo) [68:00] =============================== draft: http://tools.ietf.org/id/draft-ietf-speermint-requirements-03.txt slides: http://www3.ietf.org/proceedings/07dec/slides/speermint-3/sld1.htm defines a reference peering architecture for SPEERMINT status: is in version 04, received some feedback. stopped updating it because other drafts changed quickly. now that terminology is settling, new version is in the pipeline. major changes currently underway: aligning with terminology draft and requirements draft. a bit confused about certain terminology. SF / SBE? MF / DBE? confusion between entity and function. Daryl: my nightmare continues :). SBPE may contain SF, or not.. seperation of logical function from actual boxes required!. idea was to create logical functions, that are implemented by all those SBC etc. boxes... David: those are _logical_ functions we need to make sure we keep the seperation of logical/physical. eg. SF should not take care of NAT issues. Jason: so, some cleanup based on other drafts settling? Reinaldo: yes. also mapped terminology introduced by use-case-03 needs to remove rfc2119 language because the document is informational. changed carrier enum -> infrastructure enum (5.1.3) 5.1.5: bigger issue from Otmar still open. Jason: did we get enough feedback on 5.1.4 and 5.1.5? Reinaldo: got some good feedback, but we need more. david: are we going back and forth between use cases and architecture? daryl: this draft will a lot look like the use cases. it's an artifact of what did drive the requirements. SHOULDs and MUSTs will show up in the requirements and individual implementations of the architecture. We should have MUSTs where we define the foundation, otherwise we'll get problems in interopability. Dave: 2119 language and informational? paging an AD Jon Peterson (personal): applying 2119 to anything else than implementations is not in accordance, and imprecise. Daryl: we need to say somewhere that to accomplish things, you NEED to do certain things, that would be MUST-type language.. Jon Elwell: We need to make clear whom we're addressing in this draft. John Elwell: Who is going to do the next step? We need to say MUST somewhere... or "must"? Jon: once we get to BCPs it's a different story. SHOULDs in requirements are unclear. 2119 language was invented to help judging interopability in standards track documents. Dave: essence of the discussion: RFC2119 language in BCP yes, informational: no comment from otmar on jabber: "architecture must demonstrate that all requirements from the requirements draft are fulfilled". Reinaldo: ok, will remove/lowercase MUST. David: not sure that 5.2.1 has a lot to do with architecture. Reinaldo: you have to publish some data to peer - IETF suggests to use IETF protocols, of course. David: just define the data, not the protocol. Jason: please draft some text for this, don't leave this dead bird here. 5.4.4 - changed TLS language to "trust relationship". Otmar asked how SF-MF communication is done today - maybe put in a reference to IMS here? seems to "hang" in the current doc in a decomposed scenario. Jason: Generally - what kind of feedback do you want? reinaldo: please read, look at the flow and agree with it. This is to provide a blueprint on how people peer. check whether the architecture reflects the requirements and use cases Daryl: H.248v3 thingy is outside SPEERMINT scope. Reinaldo: of course, just an example Open discussion [97:40] ======================= otmar: requirements have a few items in which don't have a protocol solution yet. How to proceed on this? Dave: not chartered to do protocol development. AD could admit protocol development here, but we're not there yet. Jason: we might find another group who could address our need. Daryl: methods to dynamically advertise routes. would probably be sipping, not here. Security [101:00] ================= severio: we have a voip-security draft out there, which helped identify some requirements. bcp for protecting border elements used in peering? Is this work of interest to this group? jason: implementation-specific BCP is a reasonable thing to do. Group is silent... Daryl: there are well defined security practices for security between two different parties. Don't see anything new, but i haven't seen that work, too.. Dan York: There should be some text about security in requirements David: If, then it has to be unique to SPEERMINT - there's enough stuff in SIP(PING) Matt: only have a BCP if we have specific issues. However, "use existing mechanisms" pointing to other documents is neccessary. People are going to do this insecurely if we don't require some level. Other comments [108:20] ============== Sohel: cross-domain media control protocol in scope? Jon: Probably not, security problems. never contemplated that before. thinks this is out of scope. David: Policy things are completely undefined, be it regulatory issues or number ownership, one of the issues multiple answers for a destination. The real world has more than "one Bob". Jon: multihoming... Dave? Dave: in L3 world, mulitple entries, but doesn't change the identity of the endpoint. Jason: suggesting to provide a problem statement in a individual draft Wrapup: we have a couple of documents upcoming, and the xmas season is arriving. please spend some time on the docs.