On Oct 26, 2009, at 3:32 , Song Haibin wrote:
Hi,
I have not finished the review, but I have several questions on this
document.
1). I am not sure how the TRUN usage defined in this document will
work
well. Who will be responsible for calculating the turnDensity and how?
The idea was to specify the minimal simple thing and allow for much
more advanced things to be developed in the future. Right now, the
operator of the DHT would specify the turnDensity - they could
presumable measure by probing the overlay. Keep in mind the two
interesting values for overlays are no one is a TURN server and
everyone is a TURN server.
How
to update the TURN server information in the overlay when some TURN
servers
leave the overlay suddenly, to avoid getting the "old" information?
The data times out and goes away and and this is part of the reason
for finding a bunch.
2). In section 4.1.1 "Storage Permissions" said "RELOAD addresses
this issue
by only allowing any given node to store data at
a small number of locations in the overlay, with those locations
being
determined by the node's certificate." This rule will limit the
applications
that the protocol could support. E.g, for streaming or file-sharing
applications, it is very practical to put the resource providers'
address
information under the same Resource ID which is the hash of the
content
name, despite the node ID or username information contained in the
certificate of the resource provider.
Sure, but without this rules peers are would have to store an
unlimited amount of data on behalf of others. A key premise of this
work since before the WG was charter was that the protocol should be
possible to use in a way where one could deploy a overlay for some
application usage and not have it become used for file sharing. Note
that if the overlay wants to allow kinds that have no authorization
rules and allow anyone to write anywhere, there is nothing the spec
that forbids that. It's up to the usage. So if someone wants to make a
file-sharing usage, well storing the whole file in the DHT is probably
not the best design but one could certainly make a usage that did
exactly that.
3). How do you prevent "via list" being modified by the intermediate
peers?
This is very important because it is related to whether you can get
a right
returen path for your response.
Well we can't really secure this in any practical way, or more
importantly, we can prevent the intermediate peers from misrouting
the request. The misroute of the response is no more serious than the
misroute of the request. It's a pretty fundamental limitation of an
overlay system like this. However, the overlay security of the system
does not depend on stopping this. This can be used to DOS the systems
but not much else. Keep in mind, the same is true of IP that is
running over.
4). In section 5.4.2.4.2., RouteQuery response should at least
include a
next hop peer infomation if you want to use this message for the
iterative
routing.
Agree this is needed but it is somewhat DHT specific. I forget the
details but I think it was Salman who pointed out that for some
unstructured overlays, you would need something other than the next
hop. Because of that, we made the answer DHT specific. For the Chord
DHT specified here, 100% agree with you we need the next hop and the
message to return that is defined in Section 9.8
5). I'm not sure about the necessity of access control policies in
section
6.3. I think it will make sense only when these access control
policies are
generic to all usages that will be built on top of RELOAD. Other
than that,
I would suggest to remove this section and define these policies in
each
usage document. Comment 2 is also related to this topic.
Clearly many usage documents can share many of the basic policies so I
think it make more sense to define at least the ones needed for the
charter of this WG in the base draft.
Thanks!
Haibin
Thanks for reviewing it - much appreciated.
Cullen <in my individual contributor role>
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Brian Rosen
Sent: Saturday, October 24, 2009 2:55 AM
To: Cullen Jennings; P2PSIP WG
Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base
<as chair>
If you think the draft is missing something big, or has some
other serious shortcoming that makes it inappropriate to hold
a WGLC, please speak up now.
We'll give everyone a few days to look over this version, and
then decide if we will start it.
If you had signed up to review NOW would be the time to do it,
on this version. That was NOW, and not "soon", please.
Brian
On 10/23/09 2:38 PM, "Cullen Jennings" <[email protected]> wrote:
We just submitted a new version of the base draft at
http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt
(there is a new version of the sip-usage as well).
The major changes are mostly a very long and excruciating editorial
pass to try and improve the grammar.
At this point, I don't know of any significant issues that
need to be
resolved. I think the draft is ready for WGLC.
I'm sure that during WGLC some major issues will come up, some
important decisions will be made about what needs to be
mandatory and
such, and we will find several small inconsistencies and
typos in the
draft as well as things that need a clearer explanation. This will
take some time and I expect multiple more revisions for this draft
before it is published, however, I do think this is the
right time to
start WGLC. Lets get the issues on the table and then we can start
resolving them.
Thanks,
Cullen <in my individual contributor role>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
