Re: [P2PSIP] HIP: optional, mandatory?

Hi, David,

I think you're right about the !("one ring to rule them all") part.

After re-reading Henning's email down to the part that said

> On Jan 10, 2008 10:52 PM, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
>> 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.

I think we're discussing an application scenarios question.

If you can bridge two overlays, you don't need to convert to non-HIP when a 
non-HIP peer tries to join - just bootstrap a non-HIP overlay and bridge.

If that's not possible, then you need to figure out what to do when a 
non-HIP peer joins.

If the expected application is amateur video sharing, you can probably fail 
the join request and tell someone to upgrade (this is what happens when I 
try to connect to AIM with an old client, right?). That's a lot simpler than 
anything else.

If the expected application is first-responder ad-hoc, you probably 
shouldn't fail the request...

Thanks,

Spencer

> Hmmm...(b) and (c) doesn't make sense to me, unless I'm missing
> something. After reading Spencer's email, (a) and (b) make more sense
> to me.
>
> I agree with Cullen that HIP should me optional both to implement and
> run. That means that many overlays may simply not support it all, and
> others may use it exclusively, giving us the (a) scenario. A
> particular endpoint may choose to implement both, allowing it join
> both types of overlays, which is (b).
>
> (c) makes little sense to me operationally, although I guess I can see
> how it could be done technically if there are some (b) type peers that
> are effectively relays. It would make for some really odd DHTs,
> however, since you might have to route calls via the adaptors, and I'm
> not sure it really gains you anything.
>
> In my mind, this would be a capabilities negotiation issue. Although
> the mechanics of how you do it might differ a good bit, logically it
> might be good to think about it like offer-answer in SIP. If I start
> an overlay, I'm free to choose the DHT and if it is SIP or not. If, on
> the other hand a few peers were negotiating among themselves, they
> could compare capabilities (DHTs, HIP or not, security model, etc.)
> and choose the best. I don't think we have a "One ring to rule them
> all..." thing going on where every single peer is in a global overlay,
> although there could be some (very) large and essentially public
> rings. There will be rings with different choices on DHT/transport,
> and that decision may limit who can join that particular ring.
>
> So I guess since we are all picking numbers here, I am the (3)(a and
> b) camp. I might just not have my head around (c), however...anyone
> care to take a stab at explaining how it actually works?
>
> David (as individual) 

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