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