[ppsp] [Errata Verified] RFC7574 (4726)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 21 August 2017 13:58 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 4DC6913202D; Mon, 21 Aug 2017 06:58:07 -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 2DLf1o_3tsBo; Mon, 21 Aug 2017 06:58:05 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EA5132A4E; Mon, 21 Aug 2017 06:58:05 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id CC540B816CC; Mon, 21 Aug 2017 06:57:38 -0700 (PDT)
To: shkim@etri.re.kr, arno@cs.vu.nl, r.petrocco@gmail.com, victor.grishchenko@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: spencerdawkins.ietf@gmail.com, iesg@ietf.org, ppsp@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170821135738.CC540B816CC@rfc-editor.org>
Date: Mon, 21 Aug 2017 06:57:38 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ppsp/xwLEAjqLk-ln8jXfyB_m7BRCGnI>
Subject: [ppsp] [Errata Verified] RFC7574 (4726)
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: Mon, 21 Aug 2017 13:58:07 -0000

The following errata report has been verified for RFC7574,
"Peer-to-Peer Streaming Peer Protocol (PPSPP)". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid4726

--------------------------------------
Status: Verified
Type: Technical

Reported by: Sung Hei Kim, Chang Kyu Lee <shkim@etri.re.kr>;
Date Reported: 2016-07-01
Verified by: Spencer Dawkins (IESG)

Section: 6.1

Original Text
-------------
In the "Unified Merkle Tree" method, PPSPP combines the Merkle Hash
Tree scheme for static content with signatures to unify the video-on-
demand and live streaming scenarios. The use of Merkle hash trees
reduces the number of signing and verification operations, hence
providing a similar signature amortization to the approach described
in [SIGMCAST]. If PPSPP operates over the Internet, the "Unified
Merkle Tree" method MUST be used. If the protocol operates in a
benign environment, the "Unified Merkle Tree" method MAY be used. So
this method is mandatory to implement.

Corrected Text
--------------
In the "Unified Merkle Tree" method, PPSPP combines the Merkle Hash
Tree scheme for static content with signatures to unify the video-on-
demand and live streaming scenarios. The use of Merkle hash trees
reduces the number of signing and verification operations, hence
providing a similar signature amortization to the approach described
in [SIGMCAST].

Notes
-----
RFC 7574 (PPSP-PP) defines how the peers exchange chunks regarding content integrity protection scheme. It describes the relationship of the DATA and INTEGRITY messages.
But, it does not describes how peers exchange chunks when the content integrity protection scheme is disabled.
Thus, to the readers, it seems that content integrity protection scheme is very important part of PPSP-PP and must be used in order to implement PPSP-PP.
I think the RFC 7574 (PPSP-PP) should be changed to clearly express that the content integrity protection scheme must be used in PPSP-PP.
The proposed changes is to remove options regarding the use of content integrity protection.

Spencer: confirmed in conversations with Victor Grishchenko <victor.grishchenko@gmail.com>; on the PPSP mailing list.

--------------------------------------
RFC7574 (draft-ietf-ppsp-peer-protocol-12)
--------------------------------------
Title               : Peer-to-Peer Streaming Peer Protocol (PPSPP)
Publication Date    : July 2015
Author(s)           : A. Bakker, R. Petrocco, V. Grishchenko
Category            : PROPOSED STANDARD
Source              : Peer to Peer Streaming Protocol
Area                : Transport
Stream              : IETF
Verifying Party     : IESG