[17:18:16] --- enrico has joined
[17:19:08] --- enrico has left
[17:50:49] --- dumdidum has joined
[18:01:09] --- bnsmith has joined
[18:16:10] --- Yangwoo Ko has joined
[18:16:13] --- Yangwoo Ko has left
[18:18:05] --- dumdidum has left
[18:20:08] --- spencerdawkins has joined
[18:23:02] <spencerdawkins> starting the Monday BOF at IETF 67
[18:23:06] --- ctl has joined
[18:23:31] --- ctl has left
[18:25:02] --- ysuzuki has joined
[18:25:07] --- ja has joined
[18:25:16] <spencerdawkins> only two agenda items - charter and concepts doc
[18:25:19] --- richard.barnes has joined
[18:25:39] <spencerdawkins> goal is to agree on the charter.
[18:25:39] --- Jabber-Wile has joined
[18:25:42] --- hartmans has joined
[18:26:02] <spencerdawkins> if you have concerns, shame on you for not raising them on the list, but raise them now
[18:26:04] --- lemmakin has joined
[18:26:25] --- mlepinski has joined
[18:26:26] <hartmans> Send mail to ticket@noc.ietf.org or whatever the noc address is.
[18:26:28] <spencerdawkins> will do concepts for 30 minutes, then charter, then concepts if time remains
[18:26:39] <spencerdawkins> Philip presenting
[18:26:45] --- cullenfluffyjennings@gmail.com has joined
[18:27:19] <spencerdawkins> draft is product of four authors, very contentious
[18:27:24] <cullenfluffyjennings@gmail.com> starting on p2p-sip-concepts-03 draft
[18:27:41] <spencerdawkins> please let philip do his slides first, doing tutorial because this is a BOF
[18:28:03] <spencerdawkins> turorial, then recent changes, then open issues
[18:28:13] <spencerdawkins> please don't sweat the names for now - focus on concepts
[18:28:24] --- alfredh has joined
[18:28:40] --- csp has joined
[18:28:43] <spencerdawkins> goal is to set up a framework to discuss the design. Not making design choices in this document
[18:29:17] <spencerdawkins> P2PSIP is a suite of protocols that extends SIP to use P2P techniques for looking up and reaching users
[18:29:47] <spencerdawkins> Overlay is an association of P2PSIP nodes, providing registration, lookup, and SIP request routing
[18:30:16] --- mlepinski has left: Computer went to sleep
[18:30:17] <spencerdawkins> two kinds of nodes, peers and clients
[18:30:35] <spencerdawkins> peers understand the topology and stores data for the overlay
[18:30:38] <spencerdawkins> clients do not
[18:30:49] <spencerdawkins> peers have unique identifiers in the overlay, clients may not
[18:30:51] --- mlepinski has joined
[18:31:12] <spencerdawkins> peers and clients may also be coupled with a SIP entity (like a UA) - lots of examples
[18:31:26] --- Yangwoo Ko has joined
[18:31:27] --- Yangwoo Ko has left: Lost connection
[18:31:52] --- jean-francois has joined
[18:32:00] <spencerdawkins> Still some discussion about the difference between resources and users (not sure there is a difference, still a topic under discussion)
[18:32:08] --- bhoeneis has joined
[18:32:29] <spencerdawkins> also still discussing whether there are multiple types of resources or users
[18:32:37] --- enrico has joined
[18:33:01] <spencerdawkins> rohan - is there any user that's not a resource? ignore this for now
[18:33:27] <spencerdawkins> enrollment vs insertion - enroll, then insert, then make or take a call
[18:34:00] <spencerdawkins> somewhat equivalent to SIP registration
[18:34:18] <spencerdawkins> two protocols, a peer protocol and a client protocol
[18:35:03] <spencerdawkins> client protocol is a logical subset of the peer protocol (may differ syntactically)
[18:35:15] <spencerdawkins> peers can do more than clients
[18:35:38] <spencerdawkins> clients don't enroll, don't insert into overlay
[18:36:04] <spencerdawkins> both can enroll and insert users into overlay
[18:36:45] <spencerdawkins> peer protocol will support peers behind NATs, so will have some sort of NAT traversal
[18:36:50] --- dumdidum has joined
[18:37:11] <spencerdawkins> don't know what connection topology we will have between peers - showing as a box for now
[18:38:07] <spencerdawkins> document has three sample message flows, philip is showing client making a call to a peer (see slides for details)
[18:40:14] <spencerdawkins> open issues (problem with document itself) - design questions are known omissions - section 4 of the document, not going through these now, appropriate for WG consideration
[18:41:03] --- Antoin has joined
[18:41:54] --- woj has joined
[18:41:54] <spencerdawkins> major changes - removed short forms, split resource identifier in two, added concept of P2PSIP Bootstrap Peer, noted design possibility that client protocol might be SIP, added discussion of operations supported by peer protocol and client protocol
[18:42:08] <spencerdawkins> ("might not have clients" if client protocol is SIP)
[18:42:53] <woj> does anyone know where one could get the slides from?
[18:42:58] <spencerdawkins> removed mention of SEND (actually, moved to open issue), new reference diagram, some cleanups
[18:43:12] <spencerdawkins> don't know - checked proceedings page yet?
[18:44:13] <spencerdawkins> major open issues - resource/user, names, EKR third alternative design model, NATs in examples, peer support for all services (or some way to discover what services a peer DOES support)
[18:45:10] <spencerdawkins> henning - fundamental difference between client protocol and peer protocol - could have multiple client protocols, but more than one peer protocol would be problematic
[18:45:33] <spencerdawkins> (haven't discussed this yet)
[18:45:49] --- rjaksa has joined
[18:46:13] <bhoeneis> Is this presentation somewhere downloadable? I could not find it on https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
[18:46:14] <spencerdawkins> EKR - two view of universe, one is where peers are gateways, other is clients are peers with bad memories
[18:47:03] <spencerdawkins> whole virtue of this is that you're self-configuring. you may be opening up a requirement for configuration
[18:47:20] <spencerdawkins> Philip - not sure how NAT traversal works in EKR's model
[18:47:35] <spencerdawkins> Henning - concepts document isn't a specific design, it's one possibility.
[18:47:58] <spencerdawkins> if overlay consists of only peers, that's allowed in the concepts drafts
[18:48:15] --- jean-francois has left
[18:48:26] <spencerdawkins> not ready to rule out "second-class citizens", this is done in all deployed P2P systems today
[18:48:37] <spencerdawkins> hard topic we have skirted directly so far
[18:48:44] <spencerdawkins> also has a trust issue
[18:49:11] <spencerdawkins> in no way precludes an overlay that refuses to admit clients
[18:50:09] <spencerdawkins> ted hardie - confused now - can a client join an overlay multiple times?
[18:50:55] <spencerdawkins> if peers offer multiple resources, do clients join multiple times to use multiple services?
[18:51:35] <spencerdawkins> henning - people have two concepts, of an IP address and a logical entity
[18:52:05] <spencerdawkins> just need to be clear about what we mean here
[18:52:21] --- woj has left
[18:52:39] <spencerdawkins> continue discussion on list ---------------------------------
[18:52:44] <spencerdawkins> charter discussion
[18:52:52] --- woj has joined
[18:53:04] <spencerdawkins> many people helped write this charter
[18:53:27] --- sbotzko has joined
[18:53:56] <spencerdawkins> DESCRIPTION OF THE WORKING GROUP
[18:54:13] <spencerdawkins> First paragraph is 100,000 foot description
[18:55:00] <cullenfluffyjennings@gmail.com> http://www.p2psip.org/charter_061103.php
[18:55:05] --- jfischl has joined
[18:55:05] <spencerdawkins> second paragraph is more focused
[18:55:39] <spencerdawkins> peer resolution service is an alternative to RFC 3263 process
[18:55:41] --- woj has left: Replaced by new connection
[18:56:27] <spencerdawkins> rohan - don't like references in charters - just say "have documented", period.
[18:57:43] <spencerdawkins> Richard stasney - terminology mismatch with concepts draft? will look at this if it's confusing
[18:58:46] <spencerdawkins> jonathan - Discovery of TURN services, etc.? Unclear and waffly. In scope or out of scope? This text says RFC 3263 period, so TURN service discovery is out of scope
[18:59:09] <spencerdawkins> we all agree on the charter so far??????????? no objections noted
[18:59:43] <spencerdawkins> PRIMARY TASKS
[19:00:13] <spencerdawkins> Overview document, peer protocol, client protocol, applicability statement
[19:01:15] <spencerdawkins> WG determines whether either or both protocols are SIP or not
[19:02:05] <spencerdawkins> Rohan - does 3rd bullet leave possibility of a separate protocol? Didn't get this from the text
[19:02:40] --- eburger has joined
[19:03:14] <spencerdawkins> does the client protocol need to be "optionally"? Cullen says no - can update if necessary, could also have more than one type of client protocols
[19:03:50] <spencerdawkins> ???? confused by title - P2PSIP but adding other protocols?
[19:04:35] <spencerdawkins> notion is distributed lookup mechanism for SIP, may have other protocols as part of the mechanism...
[19:04:56] <spencerdawkins> Brian - concepts text is more clear on this, need to steal text from there for the charter
[19:05:48] <spencerdawkins> EKR - like "logical subset" language, want some more. We're getting at semantic difference between a client and a peer, don't want to wordsmith this here
[19:06:11] <spencerdawkins> define what we mean by "logical subset"
[19:06:46] <spencerdawkins> Brian - don't wordsmith in front of hundreds of people, but want everyone to be happy - will not have another BOF to explain the charter
[19:07:36] <spencerdawkins> Ted - "wanting to be clear about location aspect" - task 4 introduces concept of user, and hasn't been explained yet.
[19:08:44] <spencerdawkins> joel - not just SIP, but presence and status, so I'm starting to get confused when we get past "SIP INVITE"
[19:09:01] <spencerdawkins> "Does this cover a SUBSCRIBE request?"
[19:09:49] <spencerdawkins> Is this some kind of architectural document, or framework, or ... in 4. "applicability statement" seems to be the blessed term at IETF.
[19:10:15] <spencerdawkins> can revisit this term, but it's in 2026.
[19:11:05] <spencerdawkins> ??? confused about term "centralized" - no infrastructure that's planted anywhere? does this mean each domain has its own server? Would that meet the requirements?
[19:11:20] <spencerdawkins> we're talking about very, very distributed in this context.
[19:11:44] <spencerdawkins> mailing list discussion - may use a certificate server, for example.
[19:11:51] --- isudo has joined
[19:12:15] <spencerdawkins> Philip - distributed as much as we can (actually, he said "centralized" but everyone laughed)
[19:12:38] <spencerdawkins> jonathan - unconvinced you can do NAT traversal without supernodes
[19:12:49] <spencerdawkins> david - this is OK
[19:13:27] <spencerdawkins> EKR - minimize property that there is unique infrastructure that has to be online for this to work
[19:14:21] <spencerdawkins> Rohan - this discussion isn't relevant to the charter, can talk about this later
[19:14:38] <spencerdawkins> jonathan - as long as you aren't ruling out supernodes
[19:15:05] <spencerdawkins> ??? do we expect this to be one big overlay? Is routing between overlays in charter? Not in the early stages
[19:15:30] <spencerdawkins> Use classic CS-SIP between overlays
[19:15:47] <spencerdawkins> what technical design choices have already been made?
[19:16:35] <spencerdawkins> we will not be focused on other applications, only on support of SIP. Can't stop someone from reusing technology.
[19:16:59] <spencerdawkins> Out of scope, at least now.
[19:17:21] <spencerdawkins> Henning - we've done two strawman designs and this didn't matter. Ignore it and move on.
[19:17:43] <spencerdawkins> any other issues?
[19:18:25] --- ctl has joined
[19:18:26] <spencerdawkins> Rohan - need primary task to show interoperation with ordinarily SIP (encapsulated in 4? unclear to Rohan).
[19:18:34] <spencerdawkins> adding a single sentence would be fine.
[19:18:52] <spencerdawkins> OTHER WGs, NATS, ANONIMITY
[19:19:38] <spencerdawkins> SIP, SIMPLE, SIPPING, BEHAVE, MMUSIC. changes to SIP happen within SIP change process, NAT traversal happens in BEHAVE/MMUSIC
[19:20:05] <spencerdawkins> jonathan - "these"? means "behave and mmusic"
[19:20:17] <spencerdawkins> does this make jonathan happy? yes
[19:21:22] <spencerdawkins> any other comments? none noted
[19:21:51] <spencerdawkins> cullen - we wrote the anonymity text at the last bof, move on
[19:22:01] <spencerdawkins> EXCLUDED TOPICS
[19:23:23] <spencerdawkins> no discussion noted here
[19:23:30] <spencerdawkins> GOALS AND MILESTONES
[19:24:04] <spencerdawkins> Rohan - AS is informational? probably right
[19:24:22] <spencerdawkins> jonathan - sept 2007 is nearly a year. Do you need that long?
[19:24:40] <spencerdawkins> Brian - not bad to allow time in the IETF
[19:24:55] <spencerdawkins> David - hard decisions are probably coming out here.
[19:25:17] --- Antoin has left
[19:25:25] <spencerdawkins> Henning - by Sept 2007 we'll have a notion of what the protocol really looks like
[19:26:06] <spencerdawkins> henning - AS - is this consumer warning, could have been architecture or framework...
[19:26:35] <spencerdawkins> cullen - be clear on the content of the document
[19:26:49] <spencerdawkins> how the pieces we produce are tied together and interact
[19:27:20] <spencerdawkins> jonathan - is this like the NAT scenarios document in SIPPING?
[19:27:36] <spencerdawkins> david - very likely dead-on, or a little bigger
[19:27:51] <spencerdawkins> Rohan - SIPPING used "usage document"
[19:28:36] <spencerdawkins> DAVID SUMMARIZING WHAT PEOPLE HAVE SAID (going down the list)
[19:31:37] --- Jabber-Wile has left
[19:31:49] <spencerdawkins> All this goes to the mailing list as usual, then we ask to be chartered, want to do this quickly, hope we've done all our homework
[19:32:20] --- jfischl has left
[19:32:36] <spencerdawkins> modulo suggested changes, do we have room consensus?
[19:33:17] <spencerdawkins> is this the charter, for WG charter? no hums opposed noted...
[19:33:22] --- cullenfluffyjennings@gmail.com has left: Logged out
[19:33:27] --- csp has left
[19:33:27] --- enrico has left
[19:33:37] --- lemmakin has left
[19:33:37] --- ja has left
[19:34:34] --- ysuzuki has left
[19:36:45] --- eburger has left
[19:36:47] --- spencerdawkins has left
[19:38:29] --- isudo has left
[19:40:54] --- mlepinski has left: Logged out
[19:41:49] --- mlepinski has joined
[19:42:11] --- rjaksa has left
[19:47:51] --- mlepinski has left
[19:49:42] --- sbotzko has left
[19:52:27] --- richard.barnes has left
[19:53:57] --- ctl has left
[19:57:24] --- bhoeneis has left
[20:09:33] --- dumdidum has left: Replaced by new connection
[20:31:47] --- spencerdawkins has joined
[20:38:54] --- spencerdawkins has left
[21:40:07] --- admin has joined
[21:40:33] --- admin has left