Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06
Marc Petit-Huguenin <petithug@acm.org> Fri, 15 February 2013 16:51 UTC
Return-Path: <petithug@acm.org>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8BE21F87CA for <p2psip@ietfa.amsl.com>; Fri, 15 Feb 2013 08:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.5
X-Spam-Level:
X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYxK5rJOOk9a for <p2psip@ietfa.amsl.com>; Fri, 15 Feb 2013 08:51:07 -0800 (PST)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 8F58821F851C for <p2psip@ietf.org>; Fri, 15 Feb 2013 08:51:07 -0800 (PST)
Received: from [IPv6:2601:9:4b80:32:41f3:2c5b:5b9c:ed3e] (unknown [IPv6:2601:9:4b80:32:41f3:2c5b:5b9c:ed3e]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id D75C02045D; Fri, 15 Feb 2013 16:51:05 +0000 (UTC)
Message-ID: <511E6779.80706@acm.org>
Date: Fri, 15 Feb 2013 08:51:05 -0800
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version: 1.0
To: Joscha Schneider <j.schneider@hs-mannheim.de>
References: <1359673911.4472.18.camel@acorde.it.uc3m.es> <511D341E.6060905@acm.org> <511E0E0B.6070103@hs-mannheim.de>
In-Reply-To: <511E0E0B.6070103@hs-mannheim.de>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org
Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Feb 2013 16:51:08 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 One comment below. On 02/15/2013 02:29 AM, Joscha Schneider wrote: > 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: I did a review of this > draft, and I have some concerns. > [...] > > - 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. The RedirServiceProvider Data Structure does not need to be understood by the peer storing it, but you are right about the Access Control rule. My own draft about storing the Access Control rule solves this problem but, even if it is accepted as WG item, we do not want to add a normative reference to it. So I withdraw what I said - redir needs to be a a mandatory extension at least until new access control policies no longer have to be hardcoded. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRHmd3AAoJECnERZXWan7E/9oP/3Xg287LlkSKl6F2BaHXHsdc 0gS1S5BOCmJhT+q1YyCDnH0T3MPxkFJYRkEnxKNiaeQl+IUFD5AjBIDCtk/yvwb3 WNc7RueobmpypUVe/b5L/zGGTpK9jBUiguBBTw/YAiYvsp1VinBVLu7xnQGnHnA9 bWgErqYT8/w6d7r/ZgYLHl0md5mCGUihIpS0jOXxBwbUDHbK51DlE2nZmezZ5q3b zLl7duUCqNn14RKkYMA0IReRLHtgNytJDHTbXT8hwESN6qNnKfXotm3sPT0I1BMN XDgPbFfKFBVOj8o3pPVs/9A+vxLdEJ2pXJoqhIFAir4GYF9BEXhCMgqUSdFdZoXC PEh9/YO1jvx4eSP011whfOSBv86F1nZf+9yWseBJS4IVuYhYQPXLk8ip10N0aK5K VUbDCWwD5Jn93N7lLNuS9wrQJrj3Vhw/4kLNBQ3mhl4Xr+mgXkKmme6fbzQjlnTG /zk3n04xKK/bSSGdb2zcCE6mwPJjnhkHBJMc55jCu1SPBEoTH60cU1Jf6ZV5oWtc 6HbUeBBnLRlIytNrfGS80LF59xMZknGpcJHhob65Ank1x2boVlh4bJ326x0vZqZ0 bOr2O8DTvN8H6R4T+BJmcykH4AtZXbao7C5/IwidGUPPnGvurJoUiGWwJB8uA0tz SyqHcoGQsS7CcRcOV49/ =qNZD -----END PGP SIGNATURE-----
- [P2PSIP] WGLC for draft-ietf-p2psip-service-disco… Carlos Jesús Bernardos Cano
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-d… Marc Petit-Huguenin
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-d… Joscha Schneider
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-d… Marc Petit-Huguenin
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-d… Jouni Mäenpää
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-d… Joscha Schneider
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-d… Jouni Mäenpää
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-d… Jouni Mäenpää
- Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-d… Marc Petit-Huguenin