Re: [ppsp] [Errata Verified] RFC7574 (4724)

Arno Bakker <abr800@vu.nl> Mon, 28 August 2017 18:06 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 209A2132195; Mon, 28 Aug 2017 11:06:59 -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 FNEWJAL9wvld; Mon, 28 Aug 2017 11:06:56 -0700 (PDT)
Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D401200F3; Mon, 28 Aug 2017 11:06:54 -0700 (PDT)
Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.19) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 28 Aug 2017 20:06:50 +0200
Received: from [10.0.0.106] (130.37.253.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 28 Aug 2017 20:06:51 +0200
To: RFC Errata System <rfc-editor@rfc-editor.org>, shkim@etri.re.kr, arno@cs.vu.nl, r.petrocco@gmail.com, victor.grishchenko@gmail.com
CC: spencerdawkins.ietf@gmail.com, iesg@ietf.org, ppsp@ietf.org
References: <20170821135602.062B5B810E4@rfc-editor.org>
From: Arno Bakker <abr800@vu.nl>
Message-ID: <e1e8642b-0d71-3f11-cd13-9fb116a89975@vu.nl>
Date: Mon, 28 Aug 2017 20:06:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170821135602.062B5B810E4@rfc-editor.org>
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/-3KNNba2dJbEfa407reL9S0NgsY>
Subject: Re: [ppsp] [Errata Verified] RFC7574 (4724)
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, 28 Aug 2017 18:06:59 -0000

Hello

please stop the press, if possible.

There is a simpler solution. The errata stem from an incomplete
definition of swarm ID. I communicated this to Spencer on March 14th,
2017, before Victor's post to the PPSP mailing list of March 24th.
Unfortunately, there was no communication with me afterwards.

Please advice how to update just the definition (erratum 4724), which
resolves all other errata, IMHO.

The RFC does not tell what the swarm ID is when content integrity
protection is not used. 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 the smallest output
       of the supported Merkle hash functions. For live streaming, the
       swarm ID is a public key.
"

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



On 21/08/17 15:56, RFC Errata System wrote:
> 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/eid4724
> 
> --------------------------------------
> 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: 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.
> 
> 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
>