Send P2PSIP mailing list submissions to
p2psip at ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/p2psip
or, via email, send a message with subject or body 'help' to
p2psip-request at ietf.org
You can reach the person managing the list at
p2psip-owner at ietf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of P2PSIP digest..."
Today's Topics:
1. Re: HIP for P2P SIP (Bruce Lowekamp)
2. Re: HIP for P2P SIP (Ari Keranen)
3. Re: Should draft-bryan-p2psip-reload-04 be adopted as a
workgroup item? (Brian Rosen)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Jun 2008 16:03:38 -0400
From: Bruce Lowekamp <lowekamp at sipeerior.com>
Subject: Re: [P2PSIP] HIP for P2P SIP
To: Ari Keranen <ari.keranen at nomadiclab.com>
Cc: Ari at core3.amsl.com, jonathan at vidyo.com, Henry Sinnreich
<hsinnrei at adobe.com>, P2PSIP WG <p2psip at ietf.org>, sa2086 at columbia.edu
Message-ID: <48693C1A.7010704 at sipeerior.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Ari Keranen wrote:
Bruce Lowekamp wrote:
Henry Sinnreich wrote:
On 6/27/08 11:07 AM, "Eric Rescorla" <ekr at networkresonance.com> wrote:
As Bruce indicated in a previous message, HIP needs a rendezvous
service,
and a generic P2P overlay like RELOAD can provide such a service. In
that
respect, HIP would be a client of RELOAD, even if RELOAD itself ran
over ordinary IP.
-Ekr
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?
Locating a capable (non-NATed) rendezvous server in a distributed
environment without a centralized service provider is itself a
non-trivial problem.
Additionally, even if you have obtained a rendezvous server, you still
need a registration server (RFC5203).
Actually, in HIP you don't need a separate "registration server" to get
rendezvous service but you use the registration extension (RFC5203) to
register to the service. And for the NATed case you should use HIP relay
service, i.e., instead of forwarding just the I1 as in RVS, whole base
exchange is done trough the relaying service. This service can be
provided by a relay server [1] or, e.g., a P2PSIP overlay [2].
I think we must be in violent agreement, modulo a bit of terminology.
Labeling 5203 as defining a "registration server" is a bit of an
oversimplification, but I think accurately identifies one of the roles
the overlay would have to fulfill. And draft-ietf-hip-nat-traversal
merely identifies HIP relay as another role (ice aware) for a rendezvous
server.
I probably should have pointed to rfc5205 as well.
Anyway, the entire purpose of my email was to point out that something
needs to fulfill these two roles, and as suggested by hip-bone and
others, a p2psip overlay is well-suited for the job, particularly in an
ad hoc environment (no provisioned servers or dns). I think we both
agree on that.
Bruce
------------------------------
Message: 2
Date: Tue, 01 Jul 2008 06:57:05 +0300
From: Ari Keranen <ari.keranen at nomadiclab.com>
Subject: Re: [P2PSIP] HIP for P2P SIP
To: Bruce Lowekamp <lowekamp at sipeerior.com>
Cc: Ari at core3.amsl.com, jonathan at vidyo.com, Henry Sinnreich
<hsinnrei at adobe.com>, P2PSIP WG <p2psip at ietf.org>, sa2086 at columbia.edu
Message-ID: <4869AB11.4030206 at nomadiclab.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Bruce Lowekamp wrote:
Ari Keranen wrote:
Bruce Lowekamp wrote:
Henry Sinnreich wrote:
On 6/27/08 11:07 AM, "Eric Rescorla" <ekr at networkresonance.com> wrote:
As Bruce indicated in a previous message, HIP needs a rendezvous
service,
and a generic P2P overlay like RELOAD can provide such a service.
In that
respect, HIP would be a client of RELOAD, even if RELOAD itself ran
over ordinary IP.
-Ekr
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?
Locating a capable (non-NATed) rendezvous server in a distributed
environment without a centralized service provider is itself a
non-trivial problem.
Additionally, even if you have obtained a rendezvous server, you
still need a registration server (RFC5203).
Actually, in HIP you don't need a separate "registration server" to
get rendezvous service but you use the registration extension
(RFC5203) to register to the service. And for the NATed case you
should use HIP relay service, i.e., instead of forwarding just the I1
as in RVS, whole base exchange is done trough the relaying service.
This service can be provided by a relay server [1] or, e.g., a P2PSIP
overlay [2].
I think we must be in violent agreement, modulo a bit of terminology.
Labeling 5203 as defining a "registration server" is a bit of an
oversimplification, but I think accurately identifies one of the roles
the overlay would have to fulfill. And draft-ietf-hip-nat-traversal
merely identifies HIP relay as another role (ice aware) for a rendezvous
server.
I probably should have pointed to rfc5205 as well.
Anyway, the entire purpose of my email was to point out that something
needs to fulfill these two roles, and as suggested by hip-bone and
others, a p2psip overlay is well-suited for the job, particularly in an
ad hoc environment (no provisioned servers or dns). I think we both
agree on that.
Yes, we fully agree on that. I was just worried that some people on the
list might get the impression that you need two different servers just
to get the rendezvous service. Thanks for clarifying.
Cheers,
Ari
------------------------------
Message: 3
Date: Tue, 1 Jul 2008 00:07:54 -0400
From: "Brian Rosen" <br at brianrosen.net>
Subject: Re: [P2PSIP] Should draft-bryan-p2psip-reload-04 be adopted
as a workgroup item?
To: "Rosen, Brian" <Brian.Rosen at neustar.biz>, "'P2PSIP Mailing List'"
<p2psip at ietf.org>
Message-ID: <1ab401c8db30$0c1d9e80$bf320446 at cis.neustar.com>
Content-Type: text/plain; charset="us-ascii"
There being no objections, draft-bryan-p2psip-reload is hereby adopted as a
working group item against our p2psip peer protocol charter item.
Thanks to the authors for addressing the concerns of the work group.
Chairs will be announcing an editor in Dublin if not before.
As has been stated several times, and in keeping with IETF practice,
adoption of this draft DOES NOT MEAN that all the ideas in it stay as they
are, or the current authors decide what goes in or out. The working group
now controls the document and we have plenty of room and time to mold it to
meet all of our needs within our charter and milestone constraints.
Brian & David (as chairs)
-----Original Message-----
From: p2psip-bounces at ietf.org [mailto:p2psip-bounces at ietf.org] On Behalf
Of Rosen, Brian
Sent: Tuesday, June 24, 2008 7:49 AM
To: P2PSIP Mailing List
Subject: [P2PSIP] Should draft-bryan-p2psip-reload-04 be adopted as a
workgroup item?
As we discussed in Philly, the authors have addressed the concerns about
the readability and clarity of the prior version of the document. List
discussion so far has been confined to technical discussions on various
aspects of the protocol.
Who objects to making this draft a work group item, and reload, as
currently defined the protocol upon which to base our work?
If you do object, would you please state your reasons and what you would
prefer we do in furtherance of our charter item.
Brian (as chair)
_______________________________________________
P2PSIP mailing list
P2PSIP at ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
------------------------------
_______________________________________________
P2PSIP mailing list
P2PSIP at ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
End of P2PSIP Digest, Vol 19, Issue 1
*************************************