[10:19:47] --- psavola has joined
[10:32:59] --- newcat has joined
[10:58:35] --- okabe has joined
[11:02:00] --- jschmid has joined
[11:02:01] --- sleinen has joined
[11:02:31] --- jean-francois has joined
[11:02:52] --- tom_creighton has joined
[11:03:51] --- Melinda has joined
[11:06:57] --- jon has joined
[11:08:21] <tom_creighton> ?
[11:09:59] <jean-francois> Dave put up some slides on what is out of scope in VoIP peer
[11:10:14] <jean-francois> discussion on whether SPIT should be in or out of scope
[11:10:48] --- nm has joined
[11:10:50] <jean-francois> consensus seems that it is addressed in other wgs like SIPPING (Cullen, Gonzalo) or that it is lower prioority (Dave Oran)
[11:11:14] --- bhoeneis has joined
[11:11:21] <jean-francois> other items out of scope: interco or characteristics of underlying links
[11:11:32] <jean-francois> protocol interop or profiling
[11:11:40] <jean-francois> anything that is not using SIP
[11:11:45] <jean-francois> for establishing the interco
[11:11:48] <jean-francois> moving to what's in scope
[11:11:51] --- nm has left: Disconnected
[11:12:08] <jean-francois> spec of call routing architectures for delay sensitive communications using SIP
[11:12:21] --- okabe has left: Replaced by new connection
[11:12:26] <jean-francois> Dave Oran: this is big to be part of the scope
[11:12:27] --- okabe has joined
[11:12:44] <jean-francois> Richard Stansy: why delay sensitive and not any communication using SIP?
[11:13:22] <jean-francois> unknonw speaker: should it be clear that it is "inter-provider" communications?
[11:13:41] <jean-francois> Henry Sinreich: we should avoid terms like carriers and providers
[11:13:44] --- gregory has joined
[11:13:55] <jean-francois> Michel H: agree that we should avoid those terms
[11:14:18] <jean-francois> Dave Oran: that is why we should use between administrative domains kind of terminology
[11:14:26] <jean-francois> Patterson: what about media?
[11:15:12] <jean-francois> (speaker from Sprint): what's the def of call
[11:15:33] <jean-francois> Jon Peterson: def of RFC3261, we know it is a "dangerous" terms but is equiv of session
[11:16:57] --- bhoeneis has left: Logged out
[11:17:14] <jean-francois> Jean-Francois: is PSTN part of admin doamin
[11:17:21] <jean-francois> Dave - chair: yes
[11:17:41] <jean-francois> Jean-Francois: call routing to PSTN for emergency calls should be out of scope
[11:17:44] <jean-francois> Dave (noded)
[11:17:48] --- bhoeneis has joined
[11:17:51] <jean-francois> moving to other topic in scope
[11:18:06] <jean-francois> Specification of the various types of packet flows in such netwotrk
[11:18:17] <jean-francois> including VoIP trunking and peer-to-peer flows
[11:18:33] --- Melinda has left
[11:18:41] <jean-francois> another in-scope item: documentation of the requirements for the feedback of operational conditions
[11:18:52] --- psavola has left: Disconnected
[11:19:18] --- frodek has joined
[11:19:51] --- tom_creighton has left: Disconnected
[11:20:06] --- jijohna has joined
[11:20:27] <jean-francois> Jean-Francois: what is in scope here?
[11:20:38] <jean-francois> Cullen: what do you mean by dynamic policy?
[11:21:29] <jean-francois> Dave: we should tighten this up
[11:22:01] <jean-francois> Sohan: when you have 2 admin policies, how do you correlate the two?
[11:22:11] <jean-francois> (note sure I captured this quote correctly)
[11:22:27] <jean-francois> Sohan: what about the security requirements around the policies
[11:23:31] <jean-francois> Jon: seems complex. Jon clarifies what is around the feedback of operational conditions (mostly monitoring and management)
[11:24:14] <jean-francois> Alexander: scope clarification question: with this feedback, can I find out from one admin if I can connect to another admin domain?
[11:24:45] <gregory> anyone know where these slides are posted? or if they are?
[11:24:58] <gregory> They don't appear to be on the prelim / materials page...
[11:25:19] <jean-francois> Jon: the application of the item in scope is greater that what is thought to be in scope
[11:25:53] --- jschmid has left: Disconnected
[11:26:36] <jean-francois> slide are at:
[11:26:40] <gregory> www.1-4-5.net/~dmm/IETF/IETF64/VOIPEER
[11:26:47] <gregory> that's where the slides are located.
[11:27:26] <jean-francois> thx
[11:28:46] <jean-francois> (on-going discussions about that feedback on operation conditions and ability to apply dyn policies)
[11:29:08] --- jon has left: Disconnected
[11:29:58] <jean-francois> unknown speaker: when peering, an admin has to pass some info to the other admin domain. Is that in-scope?
[11:30:03] <jean-francois> Dave: what do you have in mind?
[11:30:06] <jean-francois> speaker: CDR
[11:30:12] <jean-francois> Dave: hold on until later
[11:30:35] <jean-francois> speaker: one says it is VoIP peering then Jon says SIP session, can this be clarified?
[11:30:52] <jean-francois> Dave: the name of VoIPeer is up in the air - up for discussipon
[11:31:09] <jean-francois> Jon: just used sip session to answer the question
[11:31:53] <jean-francois> Gregory: re: dynamic policies, thought that it would be used to enforce a policy that could be changed based on what you see from the peer, for e.g. if codec gets negotiated, we can reserve qos for that
[11:32:30] --- jijohna has left
[11:32:44] <jean-francois> Dave: we rathole on this, the bullet was high-level and what requirements about the feedback for applying dynamic policies
[11:33:09] --- mstjohns has joined
[11:33:23] <jean-francois> Richard S: we should not take policies out of the scope
[11:33:47] <jean-francois> Jon and Dave: what's in scope is the requirements for the feedback of operational conditions
[11:33:55] <jean-francois> that lead to dynamic policy
[11:33:55] --- jijohna has joined
[11:35:08] <jean-francois> Timothy Rang - question about whether subscription process being in scope
[11:35:16] <gregory> Did anyone have success getting to the slides on the URL Dave offered (and that I scribed in)?
[11:35:25] <gregory> I did not.
[11:35:27] <jean-francois> Jonathan: good point, should be considered
[11:35:45] <jean-francois> Hishcam: is it just Voice or all services including PoC or Push to talk
[11:36:41] <jean-francois> Dave is now going through the bullet point to clarify what is in scope
[11:36:44] <jean-francois> documentation is in scope
[11:36:53] <jean-francois> specifying the protocols for doing it is not in scope
[11:37:10] <jean-francois> (in documentation of the requirmenets for the feedback of operational conditions)
[11:37:50] <jean-francois> Dave: subscription processes should be in scope - trying to clarifying Jonathan and Timothy's point
[11:37:52] <jean-francois> no objections
[11:38:11] <jean-francois> Paul K: there are a lot of discussions about policies and having some clarification would help
[11:38:34] <jean-francois> Jonathan Rosenberg: clarification, should not define new mechanism around subscription processes
[11:38:51] <jean-francois> next slide titled "What's in scope" and starting with
[11:39:06] <jean-francois> BCPs regarding exchange of calls among VoIP providers
[11:39:33] <jean-francois> Paul K: s/providers/admin domains
[11:39:56] --- okabe has left: Disconnected
[11:40:11] <jean-francois> Dave Oran: here is an example: the SIP forum is completing some work on how enterprise (as in an admin) would route calls to other enterprises and terminate calls to PSTN
[11:40:22] <jean-francois> (note that Rohan spoke about that in IETF#63)
[11:40:35] <jean-francois> Dave: encourage people to look at that to see what BCP can look like
[11:40:50] <jean-francois> Richard: BCP would be useful
[11:41:28] <jean-francois> Gregory L: are we going to specify both cases, including a) 2 different IP domains b) enterprise and PSTN...
[11:41:39] <jean-francois> Dave: trying to stay away from terms like service providers...
[11:41:49] <jean-francois> Gregory: question: there are very different requirements
[11:41:54] <jean-francois> Jon: yes there are
[11:41:59] <jean-francois> where do we draw the line
[11:42:24] <jean-francois> Jon: the work done in the SIP Forum is even narrower in scope that an enterprise to carrier, and the delegation responsability between enterprise and carroers
[11:42:33] <jean-francois> Jon: VoIPeer is looking at something more general than that
[11:43:01] <jean-francois> (speaker): agree to include subscriptions between domains
[11:43:06] <jean-francois> Jon: ok, heard before
[11:43:27] <jean-francois> Ted Hardie: distinguish between the case where the ISP and VSP are the same or distinct administrative entities
[11:43:50] <jean-francois> Jon: agree with making that separation, relates to media transport and signaling separation
[11:45:06] <jean-francois> David Schwartz: important to look at different types of admin domains (enterprise, voip provider, etc)
[11:48:08] <jean-francois> (space out for a moment to go to the mike)
[11:48:44] <jean-francois> Jean-Francois: BCP should include sunny day scenarios as well as rainy day ones with different set of SIP extensions on both sides
[11:49:22] <jean-francois> (missed questions from Henry Sinreich and Martin Dolly - sorry)
[11:50:00] <jean-francois> Martin D: now talking at the chaining of administrative domains A - B - C, should be talking into account
[11:50:24] <jean-francois> (Martin talking at the L3 level)
[11:50:36] <jean-francois> Dave: not sure what we could accomplish there at L3
[11:51:40] <jean-francois> Jonathan: caution about what the notion of extensibility, and mandating the use of extensions and how service providers handle extensions
[11:52:34] --- mstjohns has left
[11:53:08] <jean-francois> Jean-Francois response: That's not what he meant. J-F doesn't care about what providers mandate. But we should look at the issues associated with cases when various operators require different headers based on policy.
[11:53:55] <jean-francois> Jon: This is the scope of SIP and SIPPING. Not appropriate for the scope of VoIPeer
[11:54:19] <jean-francois> Sohan: should look at applications
[11:54:37] <jean-francois> Sohan: and policy decision and enforcement points
[11:55:24] <jean-francois> unknown name of speaker: concerned about folks not wanting to look at "lower layers"
[11:57:02] <jean-francois> Willie: focus should not be creating new policies but making sure existing policies are applied correctly
[11:58:02] <jean-francois> Ted Hardie: Jonathan is right, we can do anything we want at Layer 5. But it would be more useful if we could take into account the cases where the SIP and IP layers are tightly integrated and the cases where they are not
[11:58:19] <jean-francois> (similar to his earlier point on ISP/VSP)
[11:58:29] <jean-francois> Henry: Ted's argument is broken
[11:59:36] <jean-francois> Henry: (summary) we should not base the L5 VoIP peering on the L3-2 layer characteristics
[11:59:59] <jean-francois> Dave: Dave understood Ted's comments as we should look at the cases where session and application is tight to packet transport
[12:00:13] <jean-francois> Jon: understood as we should be taking into account the media and signaling
[12:00:28] <jean-francois> Ted: yes media + signaling but here is another example
[12:01:05] <jean-francois> Ted: if you have layer 2 info and you know the geo location of the IP dev, then the VoIP domain can use
[12:01:28] <jean-francois> Dave Oran: agree with what Ted said but need to be careful that those connections be handled by clean abstraction
[12:02:23] --- apn has joined
[12:02:59] <jean-francois> Dave Oran: another use case: some providers want to do VoIP peering at L5, but they are also ISPs and want to know if they have BGP peering between each other
[12:03:54] <jean-francois> Pat Falstrom: they are different types of VoIP peerings, folks that have relationships at lower layers, folks that don't and a mix of those
[12:04:58] <jean-francois> Jonathan: Ted's use case is out of scope for VoIPeer because emergency calling should be out of scope of VoIPeer
[12:05:38] <jean-francois> Jonathan R: would like to rule the lower layer QoS considerations around the knowledge of the existence of BGP peering out of scope for now
[12:06:49] <jean-francois> Rich S: Agree with Dave Oran - all of these use cases are in scope.
[12:08:05] <jean-francois> J-F: Cablelabs has had conversations with cable operators on how various issues affect voice traffic. Ended up pursuing a DiffServ marking solution and have common values that all the operators agree on. So it will be useful to have recommendations that everyone can agree on.
[12:08:41] <jean-francois> (missed Rich Shockey's point - he agreed with Dave Oran's point)
[12:09:37] <jean-francois> Jon: in TSVWG and ieprep, there been a lot of work between interplay between layers
[12:09:42] --- okabe has joined
[12:09:55] <jean-francois> Jon: the protocol work is not for VoIP peer
[12:10:39] <jean-francois> Jon: there could be a BCP to refer to this work but this wg should not undertake work directly on the protocol stuff
[12:11:53] <jean-francois> Dave: polling the room - should we consider use cases that involve the interactions between L3 and L5 (not sure about L2)?
[12:12:19] --- newcat has left: Disconnected
[12:12:31] <jean-francois> Dave Oran: suggest out of scope until we have BCPs that address the rest (L5 peering), then, consider recharter
[12:12:53] <jean-francois> to take into account those potentially more complicated charter
[12:13:15] <jean-francois> Rich S: temporarily out of scope
[12:13:27] <jean-francois> ?
[12:14:04] <jean-francois> Dave: add something to the charter interactions between L3 and L5 (not sure about L2) are currentlyu out of scope
[12:14:39] <jean-francois> Dave and Jon: consensus - leave charter as-is with no escape clause that may allow the re-introduction
[12:15:15] --- herve.prigent@jabber.org has joined
[12:16:02] <jean-francois> --- next slide
[12:16:08] --- newcat has joined
[12:16:13] <jean-francois> title: division of labor with the ENUM WG
[12:16:41] <jean-francois> ENUM wg is about the structure of data for translation of e.165 into URIs
[12:17:00] <jean-francois> VoIPeer is concerned with the use of that data for use in signaling and routing real-time sessions
[12:17:08] <jean-francois> Dave asked for comments
[12:17:13] <jean-francois> no comment
[12:17:22] <jean-francois> --- next slide
[12:17:34] <jean-francois> slide titled "Deliverables and Milestones"
[12:17:56] <jean-francois> - VoIPeer terminology (info)
[12:19:09] <jean-francois> voipeer reference architecture (info)
[12:19:15] <jean-francois> etc. see slides
[12:19:31] <jean-francois> Hischam: is security and privacy in scope?
[12:19:59] <jean-francois> Dave: had taken out of the original charter for narrow the scope
[12:20:17] <jean-francois> Dave is asking if strong identities and security should be added back in scope
[12:20:52] <jean-francois> Cullen: need to be more specific about security because it is by default in, have to do it in the security consid/ sections at a minimum
[12:21:14] <jean-francois> Dave clarified: building security infrastructure for the use cases in play
[12:21:32] <jean-francois> Chris: CDR and accounting is a lot of work, out of scope
[12:21:41] <jean-francois> dAvid schwartz: privacy is important
[12:21:57] <jean-francois> Steve: need to be very careful when talking about billing vs. accounting
[12:22:49] <jean-francois> Dave wanted to call a vote on accounting but aborted
[12:23:17] <jean-francois> Martin D (AT&T): unless you address accounting, noone is going to interconnect
[12:23:50] <jean-francois> Dave: polling the room
[12:23:57] <jean-francois> tough call, no clear consensus
[12:24:13] <jean-francois> Jonathan: need to do the minimum, call identification is the minimum
[12:24:38] <jean-francois> Jonathan: 3gpp charging vector, or cablelabs packetcable dcs or call-id
[12:24:44] <jean-francois> would be great to have this solved
[12:24:56] <jean-francois> Jonathan said the above
[12:28:29] <jean-francois> Jean-Francois: this should be out of scope of VoIPeer but rather a sipping work item
[12:29:14] <jean-francois> Jonathan R: we've ignored this pb completely so far and various groups have created p-headers
[12:29:40] <jean-francois> Jonathan: agree with Jean-francois that it is a sipping item but VoIPeer could define requirements for it
[12:30:49] <jean-francois> Cullen: what happen if we don't put this in scope is that folks have to deal with it in the field
[12:31:03] <jean-francois> Dave: need to do requirements for call identification
[12:31:16] <jean-francois> Dave: polling the audience
[12:31:29] <jean-francois> clear consensus: requirements for accounting are in scope of VoIPeer
[12:32:23] <jean-francois> --- next slide: Terminology draft
[12:32:28] <jean-francois> Dave going through draft
[12:33:44] <jean-francois> Patterson: (not sure what the comment is, use non-Internet use-cases?)
[12:33:54] <jean-francois> Dave: this is the IETF
[12:34:06] <jean-francois> Patterson: ok but it is all IP
[12:35:23] <jean-francois> Dave: take to the list to bash it there
[12:35:27] <jean-francois> --- next slide
[12:35:32] <jean-francois> titled What's in the name
[12:35:41] --- Tom Phelan has joined
[12:35:51] <jean-francois> Generalize from VoIP specific to real-time
[12:36:10] <jean-francois> (that is generalize the name of the wg/bof)
[12:36:46] <jean-francois> Dave: RTCSP - real time comm service provider
[12:37:49] <jean-francois> Open Question: Should the title be kept VoIP peering? Or should the title encompass something else?
[12:38:44] <jean-francois> Jean-Francois: At previous IETF meeting in SIPPING, there was the idea of going beyong VoIP. My thought is that the work should encompass other than VoIP at layer 5.
[12:39:17] <jean-francois> Jonathan - Not doing email, but doing VoIP, presence, IM. So how about SPEER (SIP Peer).
[12:39:38] <jean-francois> General consensus that the WG, should it be formed, will be called PEER.
[12:40:05] <jean-francois> Dave: if we get chartered, SPEER looks good
[12:40:36] <jean-francois> DAve: proposal to send an updated charter by the end of next week
[12:41:08] --- Tom Phelan has left
[12:41:08] <jean-francois> Jonathan: current charter has a bunch of docs covering sub pieces of the peering pb
[12:41:25] <jean-francois> Jonathan: at the end of the day, some documents may change
[12:41:47] <jean-francois> Jonathan: propose to generalize and merge some of the deliverables
[12:42:01] <jean-francois> Dave: need to have some milestones, hence the current proposal
[12:42:24] <jean-francois> Dave: no other comments, meeting adjourned
[12:42:34] <jean-francois> DavE: thanks, this has been interesting
[12:43:50] --- okabe has left
[12:43:53] --- jean-francois has left
[12:44:07] --- jijohna has left
[12:44:23] --- newcat has left
[12:47:56] --- gregory has left
[12:50:57] --- herve.prigent@jabber.org has left: Logged out
[12:54:32] --- sleinen has left
[12:57:41] --- apn has left
[13:11:25] --- pguenther has joined
[13:11:58] --- pguenther has left
[14:03:39] --- bhoeneis has left: Logged out
[14:43:00] --- dumdidum has joined
[14:45:04] --- dumdidum has left