Re: [ppsp] AD review of draft-ietf-ppsp-peer-protocol-06

Arno Bakker <arno@cs.vu.nl> Wed, 01 May 2013 13:56 UTC

Return-Path: <a.bakker@vu.nl>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F37221F9822 for <ppsp@ietfa.amsl.com>; Wed, 1 May 2013 06:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.504
X-Spam-Level:
X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrNr78nKyL7m for <ppsp@ietfa.amsl.com>; Wed, 1 May 2013 06:56:49 -0700 (PDT)
Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 555A721F94FF for <ppsp@ietf.org>; Wed, 1 May 2013 06:56:48 -0700 (PDT)
Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 1 May 2013 15:56:47 +0200
Received: from [192.168.0.100] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 1 May 2013 15:56:47 +0200
Message-ID: <51811F77.3070903@cs.vu.nl>
Date: Wed, 01 May 2013 15:58:15 +0200
From: Arno Bakker <arno@cs.vu.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: ppsp@ietf.org
References: <517F8C7B.20106@neclab.eu>
In-Reply-To: <517F8C7B.20106@neclab.eu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [130.37.238.20]
Subject: Re: [ppsp] AD review of draft-ietf-ppsp-peer-protocol-06
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: arno@cs.vu.nl
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 May 2013 13:56:56 -0000

Hi Martin

thanks for the in-depth review. The authors will go over them in detail, 
but two remarks need to be made now. Please see inline.

On 30/04/2013 11:18, Martin Stiemerling wrote:
>
> Please find here the review of your Area Director for
> draft-ietf-ppsp-peer-protocol-06. This includes all sections except 12
> and 13.
>

The draft cannot be fully understood without reading Section 13 about 
the Security Considerations. This will resolve some of the points you 
made (channel IDs, PEX_REScert). We welcome recommendations on items 
from that section that should be moved forward in the document. Of 
course, we will look at them ourselves.


> ***High-level issues:
> 1) Merkle Hash Trees
> I have found the document very confusing on whether Merkle Hash Trees
> (MHTs) and the for the MHT required bin numbering scheme are now
> optional or mandatory. Parts of the draft make the impression that
> either of them or both or optional (mainly in the beginning of the
> document), while Section 5 and later Sections are relying heavily on MHTs.
>

MHTs are mandatory to implement for static content. I.e., all 
implementations should at least support this mechanism. It is not 
required to be used for all swarms. This is to ensure there is at least 
one secure configuration of the protocol that all implementations speak 
(an IETF goal AFAIK). So mandatory to implement, optional to use. We'll 
make sure this is clearer.

> My naive reading of the current draft is that you could rely on
> start-end ranges for chunk addressing and MHTs for content protection.
> However, I do know that this combination is not working.
>

Section 5, last paragraph clearly states: "The Merkle hash tree scheme 
can use different chunk addressing schemes.  All it requires is the 
ability to address a range of chunks." Hence, MHTs work with all 
numbering schemes defined in the spec.

What makes you think it doesn't work with start-end ranges? The 
compliant implementation is working fine with this scheme.

Regards,
       Arno