Re: [P2PSIP] Consensus calls

["David A. Bryan" <[e-mail]>]

Inline

On 3/29/07, Spencer Dawkins <[e-mail]> wrote:
> I'm basically agreeing, but asking for precision on a couple of points.
>
>
> > 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.
>
> 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).

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.

> > 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.
>
> 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.

Probably right that it was for one.

> > 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.
>
> 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).

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

> > Again, if any of this is something you disagree with, please discuss.
> >
> > Thanks,
> >
> > David
>
>
>
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
>


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

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