From nobody Thu Jun 30 19:13:03 2016 Return-Path: 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 6CFA412D0D3 for ; Thu, 30 Jun 2016 19:13:02 -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 fvxSZU0IdB8q for ; Thu, 30 Jun 2016 19:13:00 -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 C157212D0D9 for ; Thu, 30 Jun 2016 19:13:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6F4C9B81048; Thu, 30 Jun 2016 19:13:00 -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 Message-Id: <20160701021300.6F4C9B81048@rfc-editor.org> Date: Thu, 30 Jun 2016 19:13:00 -0700 (PDT) Archived-At: Cc: ppsp@ietf.org, shkim@etri.re.kr, rfc-editor@rfc-editor.org Subject: [ppsp] [Technical Errata Reported] RFC7574 (4724) X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 02:13:02 -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=4724 -------------------------------------- Type: Technical Reported by: Sung Hei Kim, Chang Kyu Lee Section: 1.3 Original Text ------------- 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. Corrected Text -------------- swarm ID Unique identifier for a swarm of peers, in PPSPP a sequence of bytes. For video on demand, 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. Notes ----- According to chapter 5 and chapter 6.1, it seems that it is not mandatory to use content integrity protection scheme. The definition of swarm ID in the original text does not define how the ID is used in environment with the content integrity protection disabled. It is possible to add new description on how swarm ID is defined in the content integrity protection scheme is disabled. Or, it is possible to remove the parts regarding content integrity protection. We propose to remove "with content integrity protection enabled" part. 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 From nobody Thu Jun 30 19:21:20 2016 Return-Path: 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 3ECD912D0D9 for ; Thu, 30 Jun 2016 19:21:19 -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 iX-xJrP-jx8W for ; Thu, 30 Jun 2016 19:21:17 -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 95F3A12D0C2 for ; Thu, 30 Jun 2016 19:21:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7DFB9B81064; Thu, 30 Jun 2016 19:21:17 -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 Message-Id: <20160701022117.7DFB9B81064@rfc-editor.org> Date: Thu, 30 Jun 2016 19:21:17 -0700 (PDT) Archived-At: Cc: ppsp@ietf.org, shkim@etri.re.kr, rfc-editor@rfc-editor.org Subject: [ppsp] [Technical Errata Reported] RFC7574 (4725) X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 02:21:19 -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=4725 -------------------------------------- Type: Technical Reported by: Sung Hei Kim, Chang Kyu Lee Section: 5 Original Text ------------- PPSPP can use different methods for protecting the integrity of the content while it is being distributed via the peer-to-peer network. More specifically, PPSPP can use different methods for receiving peers to detect whether a requested chunk has been maliciously modified by the sending peer. In benign environments, content integrity protection can be disabled. For static content, PPSPP currently defines one method for protecting integrity, called the Merkle Hash Tree scheme. If PPSPP operates over the Internet, this scheme MUST be used. If PPSPP operates in a benign environment, this scheme MAY be used. So the scheme is mandatory to implement, to satisfy the requirement of strong security for an IETF protocol [RFC3365]. An extended version of the scheme is used to efficiently protect dynamically generated content (live streams), as explained below and in Section 6.1. Corrected Text -------------- PPSPP can use different methods for protecting the integrity of the content while it is being distributed via the peer-to-peer network. More specifically, PPSPP can use different methods for receiving peers to detect whether a requested chunk has been maliciously modified by the sending peer. For static content, PPSPP currently defines one method for protecting integrity, called the Merkle Hash Tree scheme. The scheme is mandatory to implement, to satisfy the requirement of strong security for an IETF protocol [RFC3365]. An extended version of the scheme is used to efficiently protect dynamically generated content (live streams), as explained below and in Section 6.1. 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 From nobody Thu Jun 30 19:22:45 2016 Return-Path: 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 ; 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 ; 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 ; 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 Message-Id: <20160701022242.68FE5B81068@rfc-editor.org> Date: Thu, 30 Jun 2016 19:22:42 -0700 (PDT) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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