Subject: [ppsp] RFC7574 Errata

From: Arno Bakker <[email-masked]>
Date: Fri, 8 Sep 2017 11:55:59 +0200

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