Re: [P2PSIP] Consensus calls

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.

----- Original Message ----- 
From: "David A. Bryan" <dbryan@sipeerior.com>
To: "Eric Cooper" <eric_d_cooper@sympatico.ca>
Cc: "P2PSIP Mailing List" <p2psip@ietf.org>
Sent: Wednesday, March 28, 2007 5:30 PM
Subject: Re: [P2PSIP] Consensus calls

> 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 <eric_d_cooper@sympatico.ca> 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" <dbryan@sipeerior.com>
>> To: "P2PSIP Mailing List" <p2psip@ietf.org>
>> Sent: Wednesday, March 28, 2007 3:50 PM
>> Subject: [P2PSIP] Consensus calls
>>
>>
>> > 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
>> > dbryan@SIPeerior.com
>> > +1.757.565.0101 x101
>> > +1.757.565.0088 (fax)
>> > www.SIPeerior.com
>> >
>> > _______________________________________________
>> > P2PSIP mailing list
>> > P2PSIP@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/p2psip
>> >
>>
> 
> 
> -- 
> David A. Bryan
> dbryan@SIPeerior.com
> +1.757.565.0101 x101
> +1.757.565.0088 (fax)
> www.SIPeerior.com
>

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip