[ppsp] [Technical Errata Reported] RFC7574 (4726)
RFC Errata System <rfc-editor@rfc-editor.org> Fri, 01 July 2016 02:22 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 2F9EC12D0E5 for <ppsp@ietfa.amsl.com>; Thu, 30 Jun 2016 19:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.048
X-Spam-Level:
X-Spam-Status: No, score=-104.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 CpDguxD963fY for <ppsp@ietfa.amsl.com>; Thu, 30 Jun 2016 19:22:42 -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 6EF3F12D0E3 for <ppsp@ietf.org>; Thu, 30 Jun 2016 19:22:42 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 68FE5B81068; Thu, 30 Jun 2016 19:22:42 -0700 (PDT)
To: arno@cs.vu.nl, r.petrocco@gmail.com, victor.grishchenko@gmail.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, zongning@huawei.com, hishigh@sina.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20160701022242.68FE5B81068@rfc-editor.org>
Date: Thu, 30 Jun 2016 19:22:42 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ppsp/5q3Jj-CynAMR0J6wHJT0jKkhiUY>
Cc: ppsp@ietf.org, shkim@etri.re.kr, rfc-editor@rfc-editor.org
Subject: [ppsp] [Technical Errata Reported] RFC7574 (4726)
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.17
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, 01 Jul 2016 02:22:44 -0000
The following errata report has been submitted for RFC7574, "Peer-to-Peer Streaming Peer Protocol (PPSPP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7574&eid=4726 -------------------------------------- Type: Technical Reported by: Sung Hei Kim, Chang Kyu Lee <shkim@etri.re.kr> 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. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- 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
- [ppsp] [Technical Errata Reported] RFC7574 (4726) RFC Errata System