Now help me understand this

> one of the requirements for running HIP is a rendezvous service.  A
> P2PSIP peer protocol is capable of providing the rendezvous service that
> HIP requires to form connections.

HIP has been defined with a rendezvous server (RVS) in the HIP Rendezvous
Extension RFC 5204. Actually, one of the nicer properties is the
flexibility, since any node can act as a rendezvous server; that's more than
SIP can do.

What am I missing?

Henry


On 6/27/08 10:14 AM, "Bruce Lowekamp" <[EMAIL PROTECTED]> wrote:

> 
> 
> Henry Sinnreich wrote:
>> Please help me understand:
>> 
>>>     The chairs called for consensus on the question "Should we ask that
>>>     protocols developed allow HIP to be a customer of the P2Psip service,
>>>     within the constraints of the charter?"  There was no opposition.
>> 
>> Since P2P SIP would run over HIP, the customer is P2P SIP, not the other way
>> round as in the above. Just as SIP, RTP, etc. are customers of IP.
>> 
>> Was this a typo?
>> 
> 
> No, one of the requirements for running HIP is a rendezvous service.  A
> P2PSIP peer protocol is capable of providing the rendezvous service that
> HIP requires to form connections.
> 
> That question is independent of whether the P2PSIP peer protocol is
> using HIP as its transport protocol.
> 
> Bruce
> 
> 
> 
>> Thanks, Henry
>> 
>> On 6/27/08 7:46 AM, "Eric Rescorla" <[EMAIL PROTECTED]> wrote:
>> 
>>> At Thu, 26 Jun 2008 13:40:39 -0400,
>>> Bruce Lowekamp wrote:
>>>> To some extent, these questions are orthogonal to the questions about a
>>>> potential relationship between HIP and P2PSIP.
>>>> 
>>>> Using HIP in a decentralized manner requires a distributed rendezvous
>>>> service (and distributed name service).  An overlay such as have been
>>>> proposed by the various peer protocol proposals is ideal for running
>>>> such services.
>>>> 
>>>> P2PSIP requires a distributed registrar service.  This service also
>>>> requires a peer protocol (and some layers on top) and is not supplied by
>>>> HIP.
>>>> 
>>>> Now there are still some architectural questions of whether the peer
>>>> protocol connections should be formed using HIP or not and also
>>>> questions about how to provide the best interface for applications using
>>>> the services.
>>> It seems to me that we're repeating ourselves. From the minutes
>>> of PHL:
>>> 
>>>     The chairs called for consensus on the question "Should we ask that
>>>     protocols developed allow HIP to be a customer of the P2Psip service,
>>>     within the constraints of the charter?"  There was no opposition.
>>>     
>>>     The chairs called for consensus on the question "Should we structure
>>>     the P2PSIP service such that hip is a) a mandatory part of the
>>>     technical infrastructure b) an optional part of the technical
>>>     infrastrcuture c) potentially present only when it replaces IP, with
>>>     no other linkage.  Rough consensus for b as the current answer, with
>>>     further discussion as the technical documents describing p2psip
>>>     protocols progress.
>>> 
>>> Do we really need to rehash the discussions that led to this consensus
>>> call?
>>> 
>>> -Ekr
>> 
> _______________________________________________
> P2PSIP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip

Reply via email to