Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06

[Joscha Schneider <[e-mail]>]

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: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2psip