[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
- [ppsp] RFC7574 Errata Arno Bakker