I'm assuming that the goal is that a P2PSIP-compliant application will
be able to participate in any P2PSIP-compliant overlay, subject to
having code for the DHT the overlay is running. Thus, this means that
non-HIP peers must be able to be full peers. Unless the arrival of a
single non-HIP peer converts the whole overlay to non-HIP usage, this
also implies that all nodes must be able to deal with non-HIP peers,
even if they prefer to speak HIP. Among other things, they'll probably
have to implement ICE and TLS.
Thus, it's something like (b) and (c).
Henning
On Jan 10, 2008, at 10:29 PM, Spencer Dawkins wrote:
Hi, Cullen and Henning,
I guess today is a good day for me to be confused.
I thought I understood "optional to implement, optional to run", and
I understood Cullen's reasons stated below, but I'm very confused
about why "this only works if you can have mixed HIP-non-HIP" ...
... and that's probably because I'm not quite sure what "mixed HIP-
non-HIP" means.
Are you talking about
a - mixed within P2PSIP technology, so that some overlays use HIP
and others do not?
b - mixed within the same endpoint, that can join a HIP overlay and
a non-HIP overlay?
c - mixed within the same overlay, so some peers use HIP and others
do not?
I'll stop talking now ...
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
