[ppsp] RFC7574 Errata

Arno Bakker <abr800@vu.nl> Fri, 08 September 2017 09: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 5864A132ED0 for <ppsp@ietfa.amsl.com>; Fri, 8 Sep 2017 02:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgpMLbFkufx4 for <ppsp@ietfa.amsl.com>; Fri, 8 Sep 2017 02:56:04 -0700 (PDT)
Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACFF132403 for <ppsp@ietf.org>; Fri, 8 Sep 2017 02:56:03 -0700 (PDT)
Received: from PEXHB012A.vu.local (130.37.236.66) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 8 Sep 2017 11:56:00 +0200
Received: from [145.100.100.12] (130.37.253.20) by mails.vu.nl (130.37.236.66) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 8 Sep 2017 11:55:59 +0200
To: "ppsp@ietf.org" <ppsp@ietf.org>, "r.petrocco@gmail.com" <r.petrocco@gmail.com>, "victor.grishchenko@gmail.com" <victor.grishchenko@gmail.com>
From: Arno Bakker <abr800@vu.nl>
Message-ID: <7cd657e6-db08-6a0e-2e86-2bb3bcf66018@vu.nl>
Date: Fri, 8 Sep 2017 11:55:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [130.37.253.20]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ppsp/eMxW-vlVk9_5bupuyYuRo1xX2AE>
Subject: [ppsp] RFC7574 Errata
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 08 Sep 2017 09:56:06 -0000

Hello

some errata have been raised about the PPSP Peer Protocol RFC.
They were not properly discussed on this mailing list, but
unfortunately, have now been given a resolution and are marked verified
by one of our Transport Area directors:

http://www.rfc-editor.org/errata_search.php?rfc=7574

I think the resolution of these errata have not been properly discussed
(for my part due to lack of time and priority), and I do not agree with
the current resolution. So let's discuss:

The errata: The RFC is considered unclear about what happens when
content integrity protection is not used. The first erratum is 4724. It
correctly observes that the RFC does not tell what the swarm ID is when
content integrity protection is not used. Unfortunately, the errata
reporters then voice the opinion that the ability to run without
protection should be removed from the RFC and all their subsequent
errata implement that opinion.

The IESG did not ask for the removal, and I also think the no-protection
option should be kept. Therefore, the only relevant erratum is 4724. As
a resolution I propose to change the definition of a swarm ID as follows:

Original:
"swarm ID
       Unique identifier for a swarm of peers, in PPSPP a sequence of
       bytes.  For video on demand with content integrity protection
       enabled, the identifier is the so-called root hash of a Merkle
       hash tree over the content.  For live streaming, the swarm ID is
       a public key.
"

NEW
"swarm ID
       Unique identifier for a swarm of peers, in PPSPP a sequence of
       bytes.  For video on demand with content integrity protection
       enabled, the identifier is the so-called root hash of a Merkle
       hash tree over the content. For video on demand without content
       integrity protection, the identifier serves just to identify the
       swarm, and the ID's length MUST be equal to 20 bytes. For live 	
	streaming, the swarm ID is a public key.
"

Note: 20 bytes is the size of a SHA1 hash, which gives plenty of space
to use random values as identifiers without fears of ID clashes.

Apologies for the slow resolution of this erratum, IMHO it involves just
a minor underspecification in the RFC, hence the low priority.

Regards,
     Arno Bakker