Subject: [p2p-sip] My notes from the Conference Call on the Concepts draft

From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 18 Oct 2006 15:20:58 -0400

Folks:

Below are my notes from the conference call on Oct 17th on the  
Concepts draft.

- Philip

================

Attendees:
	Philip Matthews
	Spencer Dawkins
	Adrian Georgescu
	Cullen Jennings
	David Bryan
	Eunsoo Shim
	Arjun Roychowdhury
	Alan Johnston
	Frank Miller
	Scott Brim
	Sathya Narayanan
	Dean Willis
	Keith Drage
	Michael Slavich

Decisions:

1) "P2PSIP Peer-ID"  Should we use a different name? No, for now,  
stick with this term.

2) Section 4.9 should state that a central  certificate authority  
will be used to hand out certificates.

3) "P2PSIP Client": If SIP is used as the client protocol, then a SIP  
Client could be identical to
      a "standard SIP entity" (rather than a "standard SIP user  
agent" as -02 says). In other words,
      in this case, a client could be any form of SIP entity, not  
just a UA.
      [Similar wording changes may be required elsewhere in the  
document]

4) In section 4, add text that says that these are questions that the  
WG will have to address.
      In other words, the document will not take a stand on these  
until an official decision has been made
      by the WG.

5) Remove most of the "Short forms" or "Other forms" in the  
terminology section.
      If someone feels some alternative forms must be listed, they  
should send e-mail to Philip ASAP.

6) "P2PSIP Client". Can  we find a better term? No better suggestion  
right now. However, will
     add text saying that a Client is not the same as a SIP UAC.

7) Discussion of "User" vs. "Resource". No consensus. Will leave the  
text as "Resource (User)" for now
      and continue the debate later.

8) Delete second occurrence of "P2PSIP Resource (User) Record", since  
the first definition is the more general.

9) Will add a section before 3.3 that briefly describes the Get and  
Put operations of the Client protocol.
      Will delete the "Send" operation for now, but add some text  
saying that there needs  to be a way to relay
      messages through intermediate nodes to get to peers behind NATs.

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 19 Oct 2006 11:09:32 -0500

> Below are my notes from the conference call on Oct 17th on the

Cullen asked that the jabber logs also be posted to the list, just so they 
are archived.

We probably had about 40-percent coverage (teleconference participants who 
were also on jabber), so many people got to review what I was typing in real 
time and offer corrections, but not everyone did...

Thanks,

Spencer

[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&apos;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 at gmail.com has joined
[16:02:32] <cullenfluffyjennings at 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&apos;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/&apos;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&apos;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&apos;t good, id isn&apos;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 at 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&apos;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&apos;s proposal didn&apos;t require a 
client protocol that wasn&apos;t SIP
[16:23:16] <spencerdawkins> david thinks that&apos;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&apos;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&apos;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&apos;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&apos;t want to force a user to get a 
centralized certificate
[16:42:20] <spencerdawkins> don&apos;t want to prevent getting a 
certificate, just don&apos;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&apos;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&apos;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&apos;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&apos;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&apos;ll need a SEND, but 
don&apos;t put a lot of information in about this
[17:00:01] <swb> because we don&apos;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&apos;s a SEND message 
and ..." people will think we don&apos;t have a good metaphor for the design
[17:01:55] <spencerdawkins> we&apos;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 at 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&apos;re opening a can of worms that we 
can&apos;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&apos;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&apos;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&apos;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&apos;t HAVE to look for a relay, you don&apos;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&apos;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&apos;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&apos;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&apos;re probably 
looking at more than two months after the BOF before a charter - so please 
don&apos;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&apos;t slow down progress, make 
sure you don&apos;t have a small group of people agree on a call that a 
large group of people doesn&apos;t agree on later
[17:41:34] <spencerdawkins> document won&apos;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&apos;ll 
generate an hour of issues on anything
[17:45:27] <spencerdawkins> make sure you&apos;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 at gmail.com has left