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

[Marc Petit-Huguenin <[e-mail]>]

-----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?

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.

- - 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?

- - 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-----