Subject: [P2PSIP] Consensus calls

From: "David A. Bryan" <[email-masked]>
Date: Wed, 28 Mar 2007 15:50:56 -0400

There were a few hums taken at the meeting at IETF 68 in Prague, and I
would like to ask the list their thoughts on these, so that we can
truly say we have consensus on them and move on. Absence of comment
for a few days will be assumed to be agreement with the (nearly 200)
folks present.

1) With respect to draft-willis-p2psip-concepts-03, we took a hum and
agreed to adopt it as a WG item and as a start toward the overview
document mentioned in our charter. We further decided it will not be
immediately submitted to the IESG, but rather evolve to document the
decisions we make. That is, it will continue to reflect the consensus
and outline as that evolves.

2) We took a hum and agreed to design the peer protocol in such a way
that multiple DHTs could be used by the protocol, but only one at a
time (not simultaneous use of more than one within a particular
overlay). We further agreed we would have one or a very small number
of must-implement DHTs, to be determined later, for compatibility. Hum
was majority agreed, few dissent.

3) Took a hum that we should have some mechanism that allows an
unmodified SIP UA to connect to a DHT using some sort of adaptor. We
did not specify the protocols for it, how it would look etc -- just
that we want to include this functionality. Positive response to the
hum.

Again, if any of this is something you disagree with, please discuss.

Thanks,

David

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 28 Mar 2007 17:30:33 -0400

We tried in the call to avoid the client issue -- we are basically
talking about "do we provide some mechanism by which a vanilla SIP
client can get the routing information". Basically, some form of what
has been called an adaptor node or proxy-peer. The question was simply
"do we want to define this thing and make sure we can support it".

David

On 3/28/07, Eric Cooper <[email-masked]> wrote:
> Agree with 1 & 2.
>
> Don't think I understand 3.  Does 'connect to the DHT' mean operate as a client (as per one of the 3 definitions of client in the concepts draft)?
>
> Eric.
>
> ----- Original Message -----
> From: "David A. Bryan" <[email-masked]>
> To: "P2PSIP Mailing List" <[email-masked]>
> Sent: Wednesday, March 28, 2007 3:50 PM
> Subject: [P2PSIP] Consensus calls
>
>

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Eric Cooper" <[email-masked]>
Date: Wed, 28 Mar 2007 17:22:18 -0400

Agree with 1 & 2.

Eric.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 28 Mar 2007 15:57:18 -0700

>Basically, some form of what has been called an adaptor node or
proxy->peer. The question was simply "do we want to define this thing
and make >sure we can support it".

Yes. This will enable the use of most existing SIP UAs (phones, etc.),
plus ATA-style adapters,

Thanks, Henry

-----Original Message-----
From: David A. Bryan [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2007 4:31 PM
To: Eric Cooper
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Consensus calls

David

On 3/28/07, Eric Cooper <[email-masked]> wrote:
> Agree with 1 & 2.
>
> Don't think I understand 3.  Does 'connect to the DHT' mean operate as
a client (as per one of the 3 definitions of client in the concepts
draft)?

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Eric Cooper" <[email-masked]>
Date: Wed, 28 Mar 2007 20:11:56 -0400

OK.  Thanks for the clarification.  I agree that we should define and support something that enables vanilla SIP clients to get routing information (and possibly use the routing service of the overlay).

Eric.

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 29 Mar 2007 05:21:22 -0500

I'm basically agreeing, but asking for precision on a couple of points.

> and outline as that evolves.

I agree here, but am trying to understand whether you are saying that 03 
will be resubmitted, with no changes, as the 00 working group draft, or 
whether the next version of the draft, hopefully reflecting discussions in 
Prague and on list afterwards, would be submitted as the 00 working group 
draft. I tried to ask Brian this in Prague, but didn't ask clearly (it was 
late in the week).

> was majority agreed, few dissent.

I don't remember "or a very small number of must-implement DHTs" as part of 
the hum, and 
http://www3.ietf.org/meetings/ietf-logs/p2psipscribe/2007-03-21.html does 
not seem to have this, either. I would be happy with one must-implement DHT. 
I'm not sure where the idea of multiple must-implement DHTs came from. We've 
been reasoning from the example of crypto algorithms, where having at least 
two must-implements makes sense (when someone cracks DES, having everyone 
also implement 3-DES really helps you recover without waiting for the next 
release). I'm not sure why two must-implements would make sense for us. This 
doesn't even seem to have been mentioned in Prague, so I can't even disagree 
until I have a better understanding of the goal.

> that we want to include this functionality. Positive response to the

I agree with the hum, of course.

I'm slightly confused here (blame jet lag), but wouldn't saying "unmodified 
SIP UA" specify the protocol? I'm guessing you're talking about the effect 
of supporting unmodified SIP UAs on the peer protocol within the overlay (on 
the other side of the adaptor).

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 29 Mar 2007 09:14:46 -0400

Inline

> draft. I tried to ask Brian this in Prague, but didn't ask clearly (it was

I think you are correct that the hum was not specific. I assumed the
*next* version would be -00 and that the work from here out to produce
it would be done working group style.

> until I have a better understanding of the goal.

Probably right that it was for one.

> the other side of the adaptor).

I mean it doesn't make a decision about a client protocol or if one
exists and what it would be -- it just means we support generic SIP
UAs being supported somehow. Obviously they only speak SIP, but what
anything else speaks is not affected by this decision.

That reminds me of one other point. Those advocating the need for a
client *other* than an ordinary SIP UA that connects were asked to
advocate for it (on list or in the form of a draft) explaining some
scenarios where we need one. Can the folks who are interested in that
try to marshall up and start that thread? Thanks!

David

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 29 Mar 2007 16:19:45 +0300

I agree with all 3.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Thu, 29 Mar 2007 19:02:23 +0200

Agree to 1) and 2) an had some thoughts about 3).

While understanding Henrys thoughts on a good
market penetration through 3), there are more
things to consider if we connect endpoints that
do not take part in the DHT ring.

- Peers in general must be part of the DHT ring.

- Their functions however can be quite polymorph

   I can see three major implementations for peers:

   + User Peers: Integrate P2P and the user interface
     e.g. P2P Phones or soft-clients
   + Service peers: Provide Services to other peers
     e.g.: Trust- , Database-, Directory-, Billing-
           Services etc.
   + Gateway Peers: Integrate the P2P endpoint and
     some mediation device to other network, service,
     and user/CPE entities.
     e.g. PSTN gateways, SS7 Gateways,
     h.323 Gateways (Henry, sorry for that),
     SIP- Network and User-Endpoint peers, ...

Considering hum 3), we will end up in the definition
of a gateway peer towards SIP phones. In fact, this
device must mediate things like:
  - Phone numbers to peer ID's
  - Peer presence to phone presence
  - Phone signaling peer equivalents
  - Routing functions as mentioned by Eric
    are another thing to handle.

Is this adaptor 3) not an ATA for P2P a SIP
endpoint gateway?

... I can see Fritz-, Linksys- and Intertex-boxes
that act as adaptor and interconnect to SIP phones
and well standard DECT or analog phones in
future.

By all that, I definitely agree on 3)!

Of course, we need to discuss if 3) shall become a

  - BCP for implementors of such adaptors/ATAs/gateways?
  or
  - Does 3) need a standards track RFC for mediation
    specific protocol stuff we need?

Willi

>>> Again, if any of this is something you disagree with, please

---
Wilhelm Wimmreuter
mailto:[email-masked]
Tel.: +49 89 62500 70-3
Mob.: +49 151 121 64041

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 29 Mar 2007 10:44:57 -0700

> some form of what has been called an adaptor node

I agree with Willi's arguments and would like to add there are also some
very interesting mixed adaptor nodes possible, such as residential
gateways and set-top boxes that have (1) an adaptor for RJ-11 analog
phones and also (2) act as base the station for Wi-Fi connected mobile
devices.

The peer protocol for connecting the mobile devices must however be
designed with battery life in mind, while giving full access to all the
resources and routing modes of the P2P overlay (data interface, services
interface, join a multicast, do a name search, etc).

Thanks, Henry

-----Original Message-----
From: Wilhelm Wimmreuter [mailto:[email-masked]] 
Sent: Thursday, March 29, 2007 12:02 PM
To: Henry Sinnreich
Cc: David A. Bryan; Eric Cooper; P2PSIP Mailing List
Subject: Re: [P2PSIP] Consensus calls

Willi

---
Wilhelm Wimmreuter

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 Mar 2007 09:44:09 -0400

inline.

> anything else speaks is not affected by this decision.

In some respects, we don't need to do anything for this to be possible. 
One can build SIP to PSTN gateways, and it didn't require us, in the SIP 
group, to really do anything to support it. So really I think this is 
mostly a 'keep this in the back of your head' thing while designing the 
system, so you don't accidentally do something that makes this impossible.

In any case I agree with all three hums, but would prefer one DHT to be 
mandatory to implement, not more than one.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com