I can confirm that the draft might need some improvements to make the
implementation easier.
I did a basic implementation but I'm not quite sure that I handled
everything correct.
Especially the definition of the successor seams a bit unclear for me. A
simple example:
Only a single service provider with Node-ID 2 provides a service. Node
with ID 7 performs a lookup...
How should it be handled? I implemented it as follows: in case a lookup
reveals only a single service provider it must be the direct successor.
Further notice, due to the periodically triggered re-registration the
consistency of the ReDiR tree can not be always ensured. Theoretically
this can lead to failed lookup processes.
This derives from the fact that each new service provider registration
might affect the re-registration of the former service providers which
again might affect the re-registrations of other service providers.
more inline...
Regards
Joscha
Am 14.02.2013 19:59, schrieb Marc Petit-Huguenin:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I did a review of this draft, and I have some concerns.
First of all some parts of the I-D are verbatim copy of the text in the
original paper. Is that OK?
Probably because some of the text comes from a research paper, it was very
difficult to understand fro me, and I am not sure that I yet understood
everything - I still have to write an implementation of this, and
unfortunately to not have enough time to do so before the end of the WGLC. On
the other hand, I know that RELOAD.NET has an implementation, so I guess it is
implementable.
But I was not able to make sense of something in the example in section 7:
Why is the 4th peer added to level 0? Bullet 4 in Section 4.3 says "Node N
MUST continue [repeating steps 2 and 3] until it reaches either the root or a
level a which n.id is not the lowest or highest Node-ID in the interval
I(level, n.id)". In this case 4 is not the lowest or highest Node-ID in the
interval (lowest is 2, highest is 7), so why is it added to this node?
I think the example is simply following the rules. At level 1 peer 4 is
the lowest. So go up and fetch and store.
But if i reveal correct that fact caused a few headaches for me too. Why
does the store does not depend on the information that was fetched before?
BTW a similar example for the service lookup would be useful.
More comments:
- - Section 3, 3 paragraph: "contains a list of Node-IDs"
Technically each node is a Dictionary whose keys are Node-IDs and values
contain a list of Destinations.
- - Section 4.1
s/detination_list/destination_list/
- - Section 4.1
namespace is an opaque value but the charset and conversion between character
string and byte string for the namespace is not defined.
confirm
- - Section 8
The document says that the redir namespace is added to the
<mandatory-extension> element, meaning that all nodes MUST understand ReDIR,
but isn't that against one of the goal of ReDIR, which is that by using
standard Store/Fetch, only a node wishing to store or fetch has to implement
ReDIR?
I think at least the RedirServiceProvider Data Structure must be
supported. And also the Access Control Rules.
But the algorithm might not be mandatory needed.
- - Section 10.3
I think that we need a bit more explanation on what the turn-server and
voice-mail service providers are.
On 01/31/2013 03:11 PM, Carlos Jesús Bernardos Cano wrote:
Hi,
Hereby we are issuing a WGLC for draft-ietf-p2psip-service-discovery-06.
The WGLC will be open till the 15th of February. We kindly ask the WG to
review the document and provide comments.
If you have no comments and think the document is ready to be submitted to
IESG, please do send a note stating that to the WG ML.
Additional information about the document is below:
Title : Service Discovery Usage for REsource LOcation And
Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo
Filename : draft-ietf-p2psip-service-discovery-06.txt Pages : 15
Date : 2012-10-01
Abstract: REsource LOcation and Discovery (RELOAD) does not define a
generic service discovery mechanism as part of the base protocol. This
document defines how the Recursive Distributed Rendezvous (ReDiR) service
discovery mechanism used in OpenDHT can be applied to RELOAD overlays to
provide a generic service discovery mechanism.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-06
- --
Marc Petit-Huguenin
Email: [email protected]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJRHTQcAAoJECnERZXWan7EmukP/A1P3JutcxuDooxYPFjty3ua
lhhbiJTd7PLEs9jsaG9hKHjuDi2qu0BNp9Ss+ki+ybtXBNKaJwkrqNqwB3R+dXpx
Q7zamHvCUJekNmybG2kpc5IUP2MxhDzYp3paocOdF/vdWYE+re3u9WqBN1JNuCwk
E6GmfEIgw28p5wKldHPCGQrRYx6QnszsQc7F3+siFrsSEzRww7ATpUXjMCVxUfWU
KTmBh0H+9+PhoXeH6leue2v0Y5Xb1lD8HU6WmrssWYrd9rXgc3s26kzsUrATJCKc
bj7M6uiKIzUDFwaj13U6bPbldVeJWd+DhWCR2k4Y3rJIfj5bdp55ApDZnF/14v91
i/w0hnqnuiT/KEDuW+E7jsKwXq/ILKIDZqonyFlF7KuGUT3HGi9WFkc7AnkaOi5U
qgsuFEYjxkUqAbTAO7nwa9YtGX0qKHhH5SkzWpITTabu48c5FKqG0vAVpGce8z3K
AyqtwNXAz9nIL6ZwJNg9L8tLhLBQS1lePeSiN7pog4jsKD51VaT7Y1iMysA2OqRs
Nw70wF7TYh4EikCHsECPQBEI/a+cJEQSro0I4kHGGttVcEdrDqM4xdfaFYN+Ag1b
vHEf3Zzv/x820fjbfN1eoySj/qFU7Mcuw8Rik//J63HKZbmGdbaYsdrHasgaDIqk
TgSsgGCf6d5FX9TFFNvd
=u3Pi
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
