Re: [P2PSIP] Consensus calls

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

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

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

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

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