[13:44:21] --- spencerdawkins has joined
[15:39:42] --- philip_matthews has joined
[15:49:32] --- swb has joined
[15:49:38] <swb> Hey ho
[15:51:44] <philip_matthews> Hi folks. I am going to start the bridge in a minute
[15:52:07] <swb> I'm still on an internal call - be there soon
[15:52:48] <spencerdawkins> will dial in now... are people hooking up to the whiteboard application now, or should I wait?
[15:52:50] <philip_matthews> Bridge is now live
[15:53:08] <philip_matthews> I am going to start it now
[15:56:23] <philip_matthews> Whiteboard is started
[15:56:54] --- stonblue has joined
[15:57:03] <stonblue> Hello
[15:58:14] <swb> works for me
[15:58:48] <stonblue> Recording has started ...
[16:01:42] <spencerdawkins> A bunch of people listed attending -- Philip has the complete list
[16:02:19] --- cullenfluffyjennings@gmail.com has joined
[16:02:32] <cullenfluffyjennings@gmail.com> We are watching :-)
[16:03:11] <swb> Narayanan
[16:03:22] <swb> sathya
[16:05:42] <spencerdawkins> agenda bashing ---
[16:05:48] <spencerdawkins> bigger issues first
[16:06:32] <spencerdawkins> what to say about client protocol being same as SIP?
[16:06:44] <spencerdawkins> not everybody is happy with version 02 text
[16:06:52] <spencerdawkins> remove section 4 completely?
[16:07:07] <spencerdawkins> what does SEND operation mean?
[16:07:20] <spencerdawkins> "other forms" in terminology section
[16:07:26] <spencerdawkins> other major issues?
[16:07:45] <spencerdawkins> dean? - text for resource and user need to be reconcilled
[16:08:05] --- enrico has joined
[16:08:33] <spencerdawkins> dean - user record is defined twice, not the same thing, both have valid text
[16:09:47] <spencerdawkins> numeric sequence of digits that uniquely identifies a node - a key? id? or something else?
[16:10:15] <spencerdawkins> ID confuses with URI, and key implies a mechanism
[16:10:40] <spencerdawkins> david - key as hash term is what you hash to create an ID - the input, not the output
[16:11:18] <spencerdawkins> peer id and resource id?
[16:11:50] <spencerdawkins> resource name and resource identity are also terms
[16:12:01] <spencerdawkins> need to be able to talk about input and outputs
[16:12:16] <spencerdawkins> pick another name for the thing before it's hashed?
[16:12:43] <spencerdawkins> have never had a firm name for the input, but this is a sip identity...
[16:12:59] <spencerdawkins> ID is/'is not short form of identity
[16:13:16] <spencerdawkins> :-)
[16:13:34] --- enrico has left: Replaced by new connection
[16:13:36] --- enrico has joined
[16:13:49] <spencerdawkins> terms are already in code ...
[16:14:01] <spencerdawkins> are we talking about an index? That could be closer
[16:15:06] <spencerdawkins> could we have a peer id?
[16:15:31] <spencerdawkins> cullen - not going to be too confused?
[16:15:48] <spencerdawkins> dean - list discussion didn't go this direction
[16:16:12] <spencerdawkins> dean - willing to accept existing text, just want to make sure we agree
[16:16:19] <spencerdawkins> anyone looking for a change?
[16:16:44] <spencerdawkins> key isn't good, id isn't good ... if people understand, id is OK
[16:18:05] <spencerdawkins> propose that we stick with current terms until we make some decisions that may show us what the right term is
[16:18:49] <spencerdawkins> ----------------------
[16:19:08] <spencerdawkins> obtw, this is an official call and covered by note well, and being recorded
[16:19:16] <spencerdawkins> -------------
[16:19:21] --- enrico has left
[16:19:25] <spencerdawkins> clients vs SIP UAs
[16:19:48] <spencerdawkins> text in 02 says IF client protocol is SIP, client and SIP UA are the same thing (or maybe not)
[16:20:51] <spencerdawkins> would a client be different from a SIP UA if the client protocol was SIP?
[16:21:18] <cullenfluffyjennings@gmail.com> Today is says "In cases where conventional SIP is used for the P2PSIP Client protocol, this entity could be identical to a standard SIP user agent. "
[16:21:48] <spencerdawkins> (speaking as me) I'm OK with the current text until we know what the client protocol is
[16:22:01] <spencerdawkins> eunsoo - not incorrect, but confusing
[16:22:30] <spencerdawkins> "could be identical to a standard SIP COMPONENT"?
[16:22:59] <spencerdawkins> david's proposal didn't require a client protocol that wasn't SIP
[16:23:16] <spencerdawkins> david thinks that's (a) wave of the future
[16:23:42] <spencerdawkins> or other standard SIP component?
[16:24:20] <spencerdawkins> get/put as REGISTER?
[16:24:49] <spencerdawkins> REGISTER as GET would be unusual, but we think it would work
[16:25:16] <spencerdawkins> do we need a lookup protocol at all?
[16:25:41] <spencerdawkins> doing REGISTER as a search would be weird
[16:26:08] <spencerdawkins> why do all possible cases in this draft? this is what the working group is supposed to do
[16:27:11] --- enrico has joined
[16:27:11] <spencerdawkins> don't preclude something the working group might need to do
[16:27:24] <swb> by implication
[16:27:40] <spencerdawkins> why do we have the open questions section?
[16:28:00] <spencerdawkins> does it need to be the same draft?
[16:28:34] <spencerdawkins> leave them in a working document anyway?
[16:29:47] <spencerdawkins> questions in a tracker?
[16:29:47] --- enrico has left: Logged out
[16:29:54] --- enrico has joined
[16:32:02] <spencerdawkins> spencer is still whining about "endpoint" trust with peers versus clients
[16:32:27] <spencerdawkins> dean thinks this is a solvable problem. Spencer is happy
[16:33:01] <swb> I think it's going to be a big one.
[16:33:05] <spencerdawkins> cullen - 4.9/user credentials
[16:33:23] <spencerdawkins> credentials that you get when you enroll?
[16:33:59] <spencerdawkins> but they can be passwords, or certificates, or ... asymmetric, right? So they are certificates
[16:34:35] <spencerdawkins> arjun - any discussion about identity-based encryption?
[16:34:49] <spencerdawkins> this has its own issues
[16:35:24] <spencerdawkins> assuming a central certificate authority and hiearchical signing
[16:35:40] <spencerdawkins> we can do this discussion as a working group
[16:35:55] <spencerdawkins> what text should appear in 4.9?
[16:36:26] <spencerdawkins> cullen - we've chosen a central authority, but the form of the certificates could still be listed as an open issue
[16:37:31] --- arjunrc has joined
[16:37:51] <spencerdawkins> to identify a user SOME resource knows who the user is, but this may not be tied to a particular overlay
[16:38:59] <spencerdawkins> Michael - would user name be GUID?
[16:40:08] --- enrico has left: Logged out
[16:40:09] <spencerdawkins> easily bound to a key, expand to anything, unique in an overlay
[16:40:22] <spencerdawkins> dean - but you need a distinguished name
[16:40:30] <spencerdawkins> how does this work with ad hoc networks?
[16:41:32] <spencerdawkins> if everyone chooses a 160-bit number ... but this is looking for problems
[16:41:50] <spencerdawkins> don't want to force a user to get a centralized certificate
[16:42:20] <spencerdawkins> don't want to prevent getting a certificate, just don't want to require one (for my private overlay shared with friends)
[16:42:39] <spencerdawkins> protocol should provide secure communications, but people can choose to use them
[16:43:11] <spencerdawkins> cullen - BCP 41 require implementation of reasonable security. Doesn't require deployment or use, just implementation
[16:43:27] <spencerdawkins> did we just use SIP proxies supporting TLS as the touchstone?
[16:43:46] <spencerdawkins> ---------------
[16:44:04] <spencerdawkins> back to "if client protocol is SIP" - anyone disagree with current language?
[16:44:18] <spencerdawkins> could be UA or other entity
[16:44:41] <spencerdawkins> statement appears a few places in the document
[16:44:53] <spencerdawkins> 3.3, last sentence is one example (there are others)
[16:45:30] <spencerdawkins> does eunsoo need all of the places to change?
[16:45:52] <spencerdawkins> sip ua, sip proxy, or any other SIP component
[16:47:09] <spencerdawkins> in diagrams - UA PLUS a client
[16:48:02] <spencerdawkins> just extending "or other client-server SIP entity" - just "any SIP entity"
[16:48:28] <swb> No ... "identical to a standard sip entity"
[16:49:40] <spencerdawkins> have we already agreed?
[16:49:44] <spencerdawkins> :-)
[16:50:46] <spencerdawkins> we can define a client protocol, but we don't have to - anyone disagree?
[16:52:37] <spencerdawkins> we may need to describe the use of SIP as a client protocol in more detail, but we don't have to do that now
[16:53:07] <spencerdawkins> any other change around this issue?
[16:53:23] <spencerdawkins> need to be consistent throughout the document
[16:53:56] <spencerdawkins> ------------------
[16:54:01] <spencerdawkins> remove section 4?
[16:55:36] <spencerdawkins> and say "these are questions that the working group will be answering as a working group" - don't confuse firsttime reviewers (on the IESG :-))
[16:55:43] <spencerdawkins> ------------------------
[16:55:56] <spencerdawkins> get/put with no description of SEND operation
[16:56:12] <spencerdawkins> add a section before 3.3 that talks about these operations and what they mean?
[16:56:48] <spencerdawkins> focus especially on what SEND means - send messages across overlays to peers that are on the other side of a NAT
[16:58:02] <spencerdawkins> tunnel SIP and/or overlay maintenance through SEND for NAT traversal
[16:58:15] --- slavitch has joined
[16:59:28] <spencerdawkins> eunsoo thinks we need more discussion about this
[16:59:51] <spencerdawkins> Scott thinks we'll need a SEND, but don't put a lot of information in about this
[17:00:01] <swb> because we don't know what it will be for
[17:00:05] <spencerdawkins> need agreement on this to charter?
[17:00:45] <spencerdawkins> cullen - people have addresses and we route through addresses to get to people
[17:01:12] <spencerdawkins> if we start saying "there's a SEND message and ..." people will think we don't have a good metaphor for the design
[17:01:55] <spencerdawkins> we'll have time to hash this out as a working group after the BOF
[17:02:28] <spencerdawkins> cullen - we know we will have to route from A to C through B, but that may not require a SEND message
[17:02:51] <cullenfluffyjennings@gmail.com> I think a major topic is how are we going to work the signaling thought NATs
[17:03:12] <swb> and WHAT we are going to need to work through NATs
[17:03:24] <spencerdawkins> spencer: yeah, but we said BEHAVE would worry about this, or MMUSIC, or ...
[17:04:09] <spencerdawkins> we're opening a can of worms that we can't defend - just say we need to get through NATs in section 4.
[17:04:23] <spencerdawkins> -------------------------
[17:04:43] <spencerdawkins> short forms of names? useful, or remove them and use canonical terms?
[17:05:12] <spencerdawkins> only using short forms as "other people call it this"
[17:06:28] <spencerdawkins> "deprecated forms"?
[17:06:43] <spencerdawkins> did we invent the terms that are causing problems now ourselves?
[17:07:17] <spencerdawkins> mailing list is fairly new use one term now and ignore the past? but the past is two years long...
[17:08:29] <spencerdawkins> People have been calling peers nodes for a very long time... david will send the must-keep list
[17:08:51] <spencerdawkins> other people can send candidates, too
[17:09:19] <spencerdawkins> from a SIP perspective - "SIP client" means UAC. Won't this confuse developers?
[17:09:34] --- stonblue has left
[17:09:52] <spencerdawkins> "node" and "enhanced node" in p2p
[17:10:22] <spencerdawkins> very difficult to disambiguate stuff unless we come up with completely new terms
[17:11:30] <spencerdawkins> spencer is confused about clients with no servers, but we have a hybrid architecture and we've been trying to figure this out for a while
[17:11:52] <spencerdawkins> "node" reuse would actually be worse...
[17:12:35] <spencerdawkins> let's discuss "client" in a bar in San Diego
[17:12:43] <spencerdawkins> ---------------------
[17:13:01] <spencerdawkins> two definitions of user record in the draft
[17:13:12] <spencerdawkins> do we need a separate user and resource?
[17:13:28] <spencerdawkins> blow away second definition in the current draft?
[17:13:43] <spencerdawkins> none are opposed
[17:13:55] <spencerdawkins> SORRY - I typed too fast
[17:14:32] <spencerdawkins> David just missed the second use or user resource record
[17:14:50] <spencerdawkins> "of" user resource record
[17:15:56] <spencerdawkins> agree - we blow the second definition away
[17:16:24] <spencerdawkins> resource is used in P2P literature already for something else
[17:16:56] <spencerdawkins> one object has SIP URI, other just has ID
[17:17:09] <spencerdawkins> (MIGHT have a SIP URI)
[17:18:53] <spencerdawkins> eunsoo thinks we are talking about two different categories of entities
[17:19:42] <spencerdawkins> is a user special (compared to SIP)? In a normal SIP environment, you don't HAVE to look for a relay, you don't HAVE to look where a voice mail is stored...
[17:20:05] <spencerdawkins> Scott - OK with resources, but confused about users... not just human users, right?
[17:20:37] <slavitch> Off the phone but still watching jabber
[17:20:37] <spencerdawkins> users on the outside, resources on the inside?
[17:21:28] <spencerdawkins> scott thinks this, eunsoo thinks this ...
[17:24:25] <spencerdawkins> is a user a subset of resource, or is it something else?
[17:25:04] <spencerdawkins> philip - is UA in my SIP phone a user or a resource?
[17:25:25] <spencerdawkins> Scott is thinking hard - when you register, you become a resource
[17:25:42] <spencerdawkins> resources and user RECORDS - this is clearer
[17:26:15] <spencerdawkins> relay resource may not even be in the same namespace as the user...
[17:26:28] <spencerdawkins> is this a layering problem? we think so
[17:26:39] <spencerdawkins> entities in two different layers
[17:27:33] <spencerdawkins> scott - you can address my FTP client using FTP, but not my machine
[17:28:02] <spencerdawkins> philip - am I the user? is my UA a resource?
[17:28:03] <swb> or rather ... you address my machine with IP, you address my FTP server with a port
[17:28:31] <spencerdawkins> arjun - this is a logical definition. Could be a user and a resource at the same time in two different sessions
[17:29:15] <spencerdawkins> this is a layering problem
[17:30:00] <spencerdawkins> philip doesn't know what to write by Monday. Do we have to write something by Monday?
[17:32:31] <spencerdawkins> (sorry - I was distracted by real life - back now)
[17:33:06] <spencerdawkins> user resource record - record doesn't participate in communication itself
[17:33:44] <spencerdawkins> (speaking for myself) it seems like we just need a nice object model here that we don't have, quite yet
[17:33:50] <spencerdawkins> do we need one before Monday?
[17:34:58] <spencerdawkins> point of the document at this stage is to get our hands around the entities that need to be named. We can talk more later
[17:35:11] <spencerdawkins> --------------------------
[17:35:46] <spencerdawkins> one metaquestion - Philip planning to revise and submit update. Another call before San Diego?
[17:36:35] <spencerdawkins> No one is pushing for an ad hoc on Friday afternoon
[17:39:27] <spencerdawkins> Spencer pointed out that we're probably looking at more than two months after the BOF before a charter - so please don't wait until the charter to work some more
[17:39:29] <arjunrc> gtg - cya
[17:39:35] --- arjunrc has left
[17:40:06] <spencerdawkins> cullen - some calls are to solve a problem, some calls are a forcing function
[17:40:08] --- cavedon has joined
[17:40:53] <spencerdawkins> cullen - don't slow down progress, make sure you don't have a small group of people agree on a call that a large group of people doesn't agree on later
[17:41:34] <spencerdawkins> document won't be brought to closure any time soon, document will evolve as working group works
[17:41:54] <spencerdawkins> having another meeting? not before San Diego
[17:42:31] <spencerdawkins> schedule a call when we know why we need one
[17:43:59] <spencerdawkins> had a good turnout on this call, sign of success.
[17:45:07] <spencerdawkins> cullen - if you have a call, you'll generate an hour of issues on anything
[17:45:27] <spencerdawkins> make sure you're working on getting people to talk to each other, and to soften violent exchanges
[17:45:40] <slavitch> Is there a way to cleave the difference between a charter discussion and a functional discussiom?
[17:46:53] --- slavitch has left
[17:47:08] --- swb has left
[17:47:44] --- philip_matthews has left
[17:52:25] --- slavitch has joined
[17:52:58] --- slavitch has left
[18:02:42] --- cavedon has left
[18:22:53] --- cullenfluffyjennings@gmail.com has left