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

From: RFC Errata System <[email-masked]>
Date: Mon, 21 Aug 2017 06:56:02 -0700 (PDT)

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 <[email-masked]>
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 <[email-masked]> 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

---

From: Arno Bakker <[email-masked]>
Date: Mon, 28 Aug 2017 20:06:50 +0200

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
"

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

---

From: 이창규 <[email-masked]>
Date: Tue, 29 Aug 2017 02:45:53 +0000

Dear Arno Bekker,

This is Changkyu Lee, one of reporters.

It is glad to hear a new opinion regarding the errata.

Well... I don't think redefining "swarm ID" is not enough to resolve the errata.

However, the new definition can be one great step for resolving the errata.

Let see the errata one by one.

 - 4724 proposes to modify the definition of "swarm ID".

   The report comes from the description when content integrity protection is disabled.

   Your proposal clearly defines "swarm ID" for the situation and it sounds reasonable.

   However, I don't know how a peer recognizes the length of  smallest output of Merkle Hash Tree function.

   Yes, it is possible in implementation level since RFC mandates to implement Merkle Hash Tree function.

   The implementation, of course, can easily get the size, but let's think about the protocol level.

   In protocol level, logically, we cannot guarantee that a peer can get the length of Merkle Hash Tree scheme's output.

   It is because RFC describe that "If PPSPP operates in a benign environment, this scheme MAY be used.", in section 5.

  Maybe we can use your definition when we change the above description in section 5 as follows.

  "This scheme MUST be used even if PPSP operates in benign environment. However use of the scheme in benign environment

   is limited to get the output length of the scheme, and the output length will be used to decide the length of swarm ID when content

   integrity protection scheme is not used."

   Then the link will be perfect with the next sentence, "So the scheme is mandatory to implement, ~".

 - 4725 proposes to remove current description or to add a new description regarding chunk exchange.

   The report does not come from the missing link between swarm ID and content integrity protection scheme.

   It is reported because RFC does not specify how peers exchange chunks when the integrity protection scheme is not used.

   Please see section 2.2. Even in the example, there is no simple mention such as "INTEGRITY message is not used, when

   content integrity protection scheme is disabled."

 - 4726 is similar to 4724. So it can be resolved similarly.

 - 4880 can also be resolved, if RFC has clear description when content integrity protection method is not used.

Thank you again for giving great opinion.

Regards,

===========================================
Chang-Kyu Lee    <[email-masked]<mailto:[email-masked]>>
Researcher
Infrastructure Standards Research Section
Protocol Engineering Center (PEC)
ETRI(Electronics and Telecommunications Research Institute)
138 Gajeongno, Yuseong-gu, Daejeon, 305-700, KOREA
Phone: +82-42-860-6157
Fax: +82-42-861-5404
Mobile: +82-10-3215-0375
===========================================

________________________________
보낸 사람 : "김성혜" <[email-masked]>
보낸 날짜 : 2017-08-29 10:26:25 ( +09:00 )
받는 사람 : 이창규 <[email-masked]>
참조 :
제목 : FW: [Errata Verified] RFC7574 (4724)

________________________________
보낸 사람 : "Arno Bakker" <[email-masked]>
보낸 날짜 : 2017-08-29 03:07:01 ( +09:00 )
받는 사람 : RFC Errata System <[email-masked]>, 김성혜 <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
참조 : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
제목 : Re: [Errata Verified] RFC7574 (4724)

Hello

Original:

"swarm ID

a public key.

"

NEW

"swarm ID

"

Regards,

Arno Bakker

> Reported by: Sung Hei Kim, Chang Kyu Lee

> Spencer: confirmed in conversations with Victor Grishchenko on the PPSP mailing list.

---

From: Arno Bakker <[email-masked]>
Date: Tue, 29 Aug 2017 09:24:07 +0200

Hello

I kindly request this discussion be moved back to the PPSP mailing list,
before things are cast in stone and without bothering busy people.

If possible.

Regards,
      Arno Bakker

P.S. Mr. Lee, please repost to the mailing list, I do not see your post
there, despite the [email-masked] being in the CC:

On 29/08/17 04:45, 이창규 wrote:
>    In protocol level, logically, we cannot guarantee that a peer can get
> the length of Merkle Hash Tree scheme's output.
> 
>    It is because RFC describe that "If PPSPP operates in a benign
> environment, this scheme MAY be used.", in section 5.
> 
> 
>   "This scheme MUST be used even if PPSP operates in benign environment.
> However use of the scheme in benign environment
> 
>    is limited to get the output length of the scheme, and the output
> length will be used to decide the length of swarm ID when content
> 
>    It is reported because RFC does not specify how peers exchange chunks
> when the integrity protection scheme is not used.
> 
>   
> 
>    Please see section 2.2. Even in the example, there is no simple
> mention such as "INTEGRITY message is not used, when
> 
> *===========================================*
> *Chang-Kyu Lee*    <[email-masked] <mailto:[email-masked]>>
> Researcher
> *ET**RI*(*E*lectronics and *T*elecommunications *R*esearch *I*nstitute)
> *===========================================*
> 
>  
> 
>  
> 
> ------------------------------------------------------------------------
> *보낸 사람 : *"김성혜" <[email-masked]>
> *보낸 날짜 : *2017-08-29 10:26:25 ( +09:00 )
> *받는 사람 : *이창규 <[email-masked]>
> *참조 : *
> *제목 : *FW: [Errata Verified] RFC7574 (4724)
> 
>  
> 
> 
> ------------------------------------------------------------------------
> *보낸 사람 : *"Arno Bakker" <[email-masked]>
> *보낸 날짜 : *2017-08-29 03:07:01 ( +09:00 )
> *받는 사람 : *RFC Errata System <[email-masked]>, 김성혜
> <[email-masked]>, [email-masked] <[email-masked]>, [email-masked]
> <[email-masked]>, [email-masked]
> <[email-masked]>
> *참조 : [email-masked] <[email-masked]>,
> [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
> *제목 : *Re: [Errata Verified] RFC7574 (4724)
> 
>  
> 
> Hello
> 
>  
> 
>  
> 
>> 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.
> 
>  
>

---

From: 이창규 <[email-masked]>
Date: Tue, 29 Aug 2017 08:34:07 +0000

Dear Arno Bakker,

please check if you can find the post in mail archive.

Regards,

________________________________
보낸 사람 : "Arno Bakker" <[email-masked]>
보낸 날짜 : 2017-08-29 16:24:17 ( +09:00 )
받는 사람 : 이창규 <[email-masked]>, 김성혜 <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
참조 : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
제목 : Re: [Errata Verified] RFC7574 (4724)

Hello

If possible.

Regards,

Arno Bakker

> Well... I don't think redefining "swarm ID" is not enough to resolve the

> errata.

> The report comes from the description when content integrity

> protection is disabled.

> Your proposal clearly defines "swarm ID" for the situation and it

> sounds reasonable.

> However, I don't know how a peer recognizes the length of smallest

> output of Merkle Hash Tree function.

> Yes, it is possible in implementation level since RFC mandates to

> implement Merkle Hash Tree function.

> The implementation, of course, can easily get the size, but let's

> think about the protocol level.

> Maybe we can use your definition when we change the above description

> in section 5 as follows.

> Then the link will be perfect with the next sentence, "So the scheme

> is mandatory to implement, ~".

> - 4725 proposes to remove current description or to add a new

> description regarding chunk exchange.

> The report does not come from the missing link between swarm ID and

> content integrity protection scheme.

> - 4880 can also be resolved, if RFC has clear description when content

> integrity protection method is not used.

> *Chang-Kyu Lee* >

> *보낸 사람 : *"김성혜"

> *받는 사람 : *이창규

> *보낸 사람 : *"Arno Bakker"

> *받는 사람 : *RFC Errata System , 김성혜

> , [email-masked] , [email-masked]

> , [email-masked]

> *참조 : [email-masked] ,

> [email-masked] , [email-masked]

>> Or, it is possible to remove the parts regarding content integrity

> protection.

>> Spencer: confirmed in conversations with Victor Grishchenko on the

> PPSP mailing list.