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